Well, this is a weird problem. At first, I thought this is a trivial problem because one member of Gentoo RISC-V worked with upstream and solved the problem with pic. See details here. However, when using the patched tarball, I still failed to make a package.
Even weird thing is that when executing sudo chroot /path/to/buildroot
, check is able to pass. However, when using systemd-nspawn, it cannot pass the check with segment fault
, bus error
or illegal instruction
. Strace the test suite in systemd-nspawn,
riscv_flush_icache(0x3f8716a030, 0x3f8716a040, 0) = -1 EPERM (Operation not permitted)
While outside systemd-nspawn, it is pretty fine.
According to manual of systemd
--system-call-filter=
Alter the system call filter applied to containers. Takes a space-separated list of system call names or group names (the latter prefixed with "@", as listed by the syscall-filter command of systemd-analyze(1)). Passed system calls will be permitted. The list may optionally be prefixed by "", in which case all listed system calls are prohibited. If this command line option is used multiple times the configured lists are combined. If both a positive and a negative list (that is one system call list without and one with the "" prefix) are configured, the negative list takes precedence over the positive list. Note that systemd-nspawn always implements a system call allow list (as opposed to a deny list!), and this command line option hence adds or removes entries from the default allow list, depending on the "~" prefix. Note that the applied system call filter is also altered implicitly if additional capabilities are passed using the --capabilities=.
There is a default allow list of syscalls in systemd-nspawn, which is defined here. There is no architecture dependent syscall :(
As for solution, one way is asking ArchLinux devtools to export a configuration API which allows us to add RISC-V specific syscall to allow list. Another way is asking systemd to add some archtecture dependent syscall to the default allow list.