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

["H. Peter Anvin" <hpa at zytor dot com>]

On 12/30/2010 10:59 AM, H.J. Lu wrote:
> 
>> (If you could arrange for the syscall ABI always to be the same as the
>> existing 64-bit ABI, rather than needing to handle three different syscall
>> ABIs in the kernel, that might be one solution, but it could have its own
>> complexities in ensuring that none of the types whose layout forms part of
>> the kernel/userspace interface have layout differing between n32 and the
>> existing ABI; without any action, structures would tend to get layout
>> similar to that of the existing 32-bit ABI, though quite possibly not the
>> same depending on alignment peculiarities - I'm guessing that the new ABI
>> will use natural alignment - while long long arguments would tend to be
>> passed in a single register, resulting in the complicated hybrid syscall
>> ABI present on MIPS.  If you do have an all-new syscall ABI rather than
>> sharing the existing 64-bit one, I imagine it would need to follow the
>> cut-down set of syscalls for new ports, so involving the issue of how to
>> build glibc for that set of syscalls discussed three months ago in the
>> Tilera context.)
>>
> 
> You are right.  Add ILP32 support to Linux kernel may be tricky.
> We did some experiment to use IA32 syscall interface for ILP32:
> 

The current plan is to simply use the 32-bit kernel ABI more or less
unmodified, although probably with a different entry point using syscall
rather than int 0x80 for performance.  In order for the ABI to map 1:1,
there needs to be a few concessions:

a) 64-bit arguments will need to be split in user space.
b) The Linux kernel  exported __u64 type will need to be declared
   __attribute__((aligned(4))).  This will only affect a handful of
   structures in practice since implicit padding is frowned upon.

(a) could also be fixed by a different syscall dispatch table, it's not
the hard part of this.  We definitely want to avoid adding a different
memory ABI; that's the part that hurts.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.