Closed egouriou-rivos closed 1 year ago
@aswaterman for your consideration. Please let me know if you want me to file an issue to document the pre-existing failure.
I’m certainly OK with the stub, but I’m confused as to why it is needed. Reading the code, it appears that sys_stub_nosys is already called whenever there is no such call defined. Where is the “bad syscall” printout coming from?
Oh, I just didn't pay enough attention when moving from our internal version to /master . Rivos' internal version of riscv-pk is behind and doesn't contain ca69d69a.
commit ca69d69a304d5668a8c95d1de5c6c6fa71ed9936
Author: Andrew Waterman <andrew@sifive.com>
Date: Mon Apr 11 01:22:16 2022 -0700
Handle unimplemented syscalls gracefully
We previously kernel-panicked because that made it more obvious when a
syscall implementation was missing. These days, it's more common that
the C library will do something sensible in response to returning -ENOSYS.
Favor that approach to avoid frustrating users.
Never mind then. I'll move our clone of riscv-pk forward. Thanks.
Ah, right, I forgot about that. Glad you figured it out.
Binaries built with a recent LLVM and current riscv-gnu-toolchain and targeting riscv64-unknown-linux-gnu fail to execute under Spike+pk with this output:
Syscall 278 is getrandom which is invoked prior to reaching main(). Providing a syscall stub to return ENOSYS is enough to please the caller. This has the additional benefit of not requiring to implement getrandom() in a portable way.