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.