[klibc] HUGE change soon coming to a klibc near you
H. Peter Anvin
hpa at zytor.com
Sun Jun 6 15:54:22 PDT 2004
Hold on to your hats, because the world is about to break...
I have been trying to figure out for a while now how to migrate klibc to
a 64-bit off_t, and to handle other things like getuid32(). The final
decision is that the _syscall*() macros just got to go; they aren't
flexible enough, and the hope that they would make it easier to port
between platforms hasn't worked out - they're far too often simply broken.
Thus, I have worked on a new infrastructure which uses Perl to generate
assembly stubs for the system calls directly; since on most platforms
the system call calling convention closely matches the function calling
convention these assembly stubs are usually trivial. There is going to
be some funnies on the s390[x] platform or any other platforms which
goes to "pass a structure beyond X register arguments", since with
64-bit arguments those may be more than one register, but we can deal
with those too.
So far, I have i386, x86-64, ARM/Thumb, and SPARC working; SPARC-64
*mostly* works except sigaction() returns error; I'm not clear on why
since neither gdb nor strace works with 64-bit binaries on my sparc test
system; for all I know it could be a kernel problem (2.4.20-something.)
At the moment I don't have ready working access to any other platforms;
my MIPS system went to hell when I tried to upgrade it, and the remote
Alpha system I used to use has apparently pulled my access.
This will thus break *ALL* other architectures. Accordingly, I will
release 0.117 with the new stuff and ask for patches, but leave 0.116
available on kernel.org for people who want to use klibc as opposed to
The nice thing is that the syscall stub stuff is a substantial code
shrink on most platforms; on i386 it reduces klibc.so from just under
20K to just under 18K.
More information about the klibc