The x32 system call ABI [LWN.net]

The x32 system call ABI

Posted Sep 1, 2011 22:17 UTC (Thu) by hummassa (guest, #307)
In reply to: The x32 system call ABI by cesarb
Parent article: The x32 system call ABI

If you use the 64 bit structures, then you have a 64-bit userland program...
Resuming:
x86_64/amd64 => wastes space (and cache == performance), many registers
ia32 => gains space, few registers
x32 => gains space, many registers

to post comments

The x32 system call ABI

Posted Sep 5, 2011 22:05 UTC (Mon) by butlerm (guest, #13312) [Link] (1 responses)

I believe the idea here is _not_ to use 64 bit pointers everywhere, but rather to use 64 bit pointers in certain circumstances, and do one of the following:

(1) Change the source level API for all pertinent ioctl structures that contain pointers so that programs have to manually zero extend a 32 bit pointer into some sort of opaque 64 bit value.
(2) Use a compiler extension that does this transparently, i.e. that supports a special pointer type where the high order bits are always zero.

I suspect (1) would break source compatibility in far too many places, although it seems like it is what should have been done way back when these interfaces were first designed.

(2) seems ideal, but requires cooperation for every supporting compiler. I don't know exactly why, but the x32 ABI devs are trying to avoid that if at all possible.

The x32 system call ABI

Posted Sep 6, 2011 1:05 UTC (Tue) by cesarb (subscriber, #6266) [Link]

There is also:

(3) Keep the source level API 32-bit, but have glibc do the zero-extension into the true 64-bit API before calling the kernel.

The main problem with that is, of course, ioctl (the same compat ioctl problem the kernel already has). So, how about this:

(4) Same as (3) but add a new x32_ioctl 64-bit syscall which calls into the compat ioctl engine the kernel already has.