Build failure on powerpc64 and mips64

[asomers]

Thanks for the crate! I'm trying to use it for Nix's CI tests. However, the build fails for powerpc64-unknown-linux-gnu, powerpc64le-unknown-linux-gnu, mips64-unknown-linux-gnu, and mips64el-unknown-linux-gnu.

   Compiling caps v0.3.0
error[E0425]: cannot find value `CAPGET` in module `nr`
  --> /cargo/registry/src/github.com-1ecc6299db9ec823/caps-0.3.0/src/base.rs:12:40
   |
12 |     let r = unsafe { libc::syscall(nr::CAPGET, hdr, data) };
   |                                        ^^^^^^ not found in `nr`
error[E0425]: cannot find value `CAPSET` in module `nr`
  --> /cargo/registry/src/github.com-1ecc6299db9ec823/caps-0.3.0/src/base.rs:20:40
   |
20 |     let r = unsafe { libc::syscall(nr::CAPSET, hdr, data) };
   |                                        ^^^^^^ not found in `nr`
error: aborting due to 2 previous errors
error: Could not compile `caps`.

[lucab]

Thanks for reporting it. The syscalls used here aren't wrapped by libc, and requires explicit constants to be defined. Those architectures are indeed missing in src/nr.rs. If you have some time to gather CAPGET and CAPSET numbers on those four missing architectures, I'll be happy to add them and tag a new release. Otherwise, I will eventually get to them as I already had ppc64le on my roadmap.

[asomers]

I'm looking into it now. However, I can't find CAPGET and CAPSET definitions that match what you already have for aarch64. For aarch64, you use 90 and 91. But according to arch/arm64/include/asm/unistd32.h, 90 and 91 are sys_ni_syscall and sys_munmap, respectively. And for mips you use 4204 and 4205. But according to arch/mips/kernel/syscalls/syscall_o32.tbl there are no such syscall numbers. Instead the correct numbers are 204 and 205. Am I missing something?

[lucab]

Linux syscall numbers are, uhm, complicated:

• mips32: there are multiple kernel ABIs available, they all involve a base-offset. We use o32 here, whose offset is 4000. See https://www.linux-mips.org/wiki/Syscall#Compatibility_ABIs
  • aarch64: unistd32.h is only for 32bits (compat) personality. The real 64bits syscall are taken from asm-generic/unistd.h

I have (limited) access to the two architectures above, so I have tested that those syscall numbers are actually correct before merging them. When in doubt, I usually check with valgrind headers (as they have an almost complete emulation layer/table, which is easier to navigate).

[asomers]

I don't have the ability to test on any non-amd64 hardware. So I could make a patch, but I would have no confidence in its correctness. Google turned up a list of syscalls for most architectures from the Go project. Do these look correct to you? https://golang.org/src/syscall/zsysnum_linux_mips64.go .

One more reason to like FreeBSD: its syscall numbers are completely architecture-independent.

[lucab]

Ah, good reference! Yes, I just double checked and those numbers corresponds to the kernel and valgrind ones (for all the four architectures).