[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 
hack it.

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.

	-hpa



More information about the klibc mailing list