On Thu, 30 Dec 2010, H.J. Lu wrote: > On Thu, Dec 30, 2010 at 10:42 AM, Joseph S. Myers > <jos...@codesourcery.com> wrote: > > On Thu, 30 Dec 2010, H.J. Lu wrote: > > > >> Hi, > >> > >> This patch adds 32bit x86-64 support to binutils. Support in compiler, > >> library and OS is required to use it. It can be used to implement the > >> new 32bit OS for x86-64. Any comments? > > > > Do you have a public psABI document? I think the psABI at the ELF level > > needs to come before the binutils bits, at the function call level needs > > to come before the GCC bits, etc. > > The psABI is the same as x86-64 psABI, except for 32bit ELF instead of > 64bit.
I don't think that's an adequate description. If the "ILP32" name is accurate then it's certainly wrong at the C level since some type sizes are different, with effects in turn on such things as the description of initial stack layout storing argv. At the ELF level are you saying that each relocation applies to a relocatable field of the same width as for 64-bit (but with the width of the addend being restricted, of course)? Do any relocations applying to word64 fields need 32-bit variants applying to word32 for the ILP32 ABI? The right thing to do would be to go through the ABI sources and prepare a patch adding a description of the ILP32 ABI at least place where any change is needed. > > the problems that have plagued the MIPS n32 syscall ABI, which seems like > > a similar case? > > Can you describe MIPS n32 problems? Syscalls sometimes need three different versions in the kernel; sometimes the wrong version gets put in the n32 syscall table. Special syscall wrappers are often needed in glibc; although for most purposes the glibc port is a 32-bit one, including having separate functions for 32-bit and 64-bit off_t, syscalls tend to need to be called in the 64-bit way (long long values as single arguments, in particular). > You are right. Add ILP32 support to Linux kernel may be tricky. > We did some experiment to use IA32 syscall interface for ILP32: That seems likely to run into the structure layout issues I mentioned (long long only being 4-byte aligned for IA32, but 8-byte aligned for x86-64 and I presume for the new ABI). > That means we pass 64bit integers to kernel the same way as ia32. That has its own problems. If the C prototype of a system call, at the userspace level, has a 64-bit integer argument, it's desirable that the argument is passed to the kernel in the same way as it is passed to the C function implementing the syscall. This allows glibc's automatically generated syscall wrappers to work. (Note how fanotify_mark is defined to use i:iiiiis for 32-bit, i:iiiis for 64-bit - and i:iiiis for MIPS n32 because a 64-bit argument is passed in a single register for n32. Recently added syscalls have had care taken to position 64-bit arguments so that this sort of thing does work for 32-bit architectures, rather than leaving an unused register for alignment as can arise with bad positioning of the 64-bit arguments.) MIPS n32 still needs special wrappers in various cases where generic Linux needs C wrappers (posix_fadvise, fallocate, posix_fallocate, for example) but avoids them for syscalls.list cases. If the C ABI for 64-bit integers passes them in single registers (as is the natural adaptation of the 64-bit ABI), then such integers should also be passed to the kernel in single registers; otherwise you need custom wrappers for each affected syscall. But then you certainly can't use the IA32 syscall ABI.... -- Joseph S. Myers jos...@codesourcery.com
