On Thu, 6 Dec 2018, Florian Weimer wrote:
I seem to remember having to take extra care with how the three MIPS ABIs wire the syscalls to get it right in glibc, but I take it then this has been now addressed reliably enough for the glibc not to care how exactly <asm/unistd.h> has been arranged.
This is a fairly recent change (commit 2dba5ce7b8115d6a2789bf279892263621088e74, "<bits/syscall.h>: Use an arch-independent system call list on Linux", first release with it is glibc 2.27). This patch is quite backportable; we have put it into our 2.17-derived glibc, and the upstream work was originally driven by downstream ordering requirements of kernel header and glibc builds. Glad to see it's useful elsewhere.
Thanks for the pointer, and the work you have done to make this more robust; it was that that I missed.
The test retains the old <asm/unistd.h>-based macro extraction for testing purposes, but it needs that only for the actual target architecture and only the *names*, so it's easy to implement. Before that, the generation would have to carefully take into account multiple sub-targets (i386/x86-64/x32 is one of the more complicated scenarios). Presumably, you saw problem with that part.
Yeah, the MIPS o32/n64/n32 ABI set is a corresponding situation, except that somewhat longer-lived as we've had support for these three ABIs since 2001, including the ability to concurrently run user executables built for any of these ABIs under a single 64-bit Linux kernel.
Maciej