Re: RFC: Add 32bit x86-64 support to binutils

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Thu, Dec 30, 2010 at 11:30 AM, Joseph S. Myers
<joseph@codesourcery.com> wrote:
> 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?

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.