This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: RFC: Add 32bit x86-64 support to binutils
On Thu, 30 Dec 2010, H.J. Lu wrote:
> On Thu, Dec 30, 2010 at 10:42 AM, Joseph S. Myers
> <joseph@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
joseph@codesourcery.com