The x32 system call ABI [LWN.net]

The x32 system call ABI

Posted Sep 1, 2011 12:53 UTC (Thu) by cesarb (subscriber, #6266)
In reply to: The x32 system call ABI by and
Parent article: The x32 system call ABI

Why not simply use the 64-bit structures then?

When putting a pointer into these structures, it can simply be zero-extended.

Only memory allocation system calls would need a new flag (to allocate below 4G). Other than these, the kernel does not have to change at all. The rest could be done in userspace.

(The only other change needed in the kernel would be to add a flag in the executable file format to make ASLR use only the lower 32 bits.)

to post comments

The x32 system call ABI

Posted Sep 1, 2011 22:17 UTC (Thu) by hummassa (guest, #307) [Link] (2 responses)

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

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.