The x32 system call ABI [LWN.net]

The x32 system call ABI

Posted Sep 1, 2011 8:08 UTC (Thu) by slashdot (guest, #22014)
In reply to: The x32 system call ABI by njs
Parent article: The x32 system call ABI

I don't understand why they need to change the kernel and add a new "x32" ABI.

Why not just have x32 programs use the x86-64 system calls and otherwise behave as normal x86-64 programs from the kernel's perspective?

The only difference would then be that they would only use 4GB of address space (mmap with MAP_32BIT), and store pointers in 32-bit-sized locations in memory.

In fact, you could probably use #pragma and/or __attribute__ to specify pointer size, and use a 64-bit libc, while most other libraries and the executable are 32-bit.

to post comments

The x32 system call ABI

Posted Sep 1, 2011 11:56 UTC (Thu) by and (guest, #2883) [Link] (4 responses)

The problem is that some structures contain pointers which are always 64 bits in kernel space but in x32 the userspace only has 32 bits. The "new" system calls thus have to translate these pointers before the structures can be used by "normal" kernel space code.

The x32 system call ABI

Posted Sep 1, 2011 12:53 UTC (Thu) by cesarb (subscriber, #6266) [Link] (3 responses)

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.)

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.