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
