On Thu, Dec 30, 2010 at 11:30 AM, Joseph S. Myers <jos...@codesourcery.com> wrote: > 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?
ILP32 uses small model in x86-64 psABI. > 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. That is on my TODO list. I am planning to publish an ILP32 psABI. >> > 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.... > We will address those issues if we want to support ILP32 on Linux. -- H.J.
