klibc - Jun 2004 - HUGE change soon coming to a klibc near you

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

Patrick J. LoPresti wrote:
> "H. Peter Anvin" <hpa@zytor.com> writes:
> 
> 
>>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.
> 
> 
> Some of us would not mind seeing each klibc release hang around for a
> minimum amount of time (say, 6 or even 12 months), because we
> distribute automated scripts for downloading/building/installing
> particular versions.
> 
> Just FYI :-).
> 
>  - Pat
What I've done for now is create a "Stable" directory with the
intention
of moving releases which have shown to be OK there.  Those will stick 
around.  Does that do what you need it to?

	-hpa

On Sun, Jun 06, H. Peter Anvin wrote:
> 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.
How does the new scheme deal with types? Some syscalls return int, some
void * or other things.
mmap on ppc64 would return a long int instead of a void *. errno is also
not handled correctly.

-- 
USB is for mice, FireWire is for men!

sUse lINUX ag, n?RNBERG