3 ms·
It's an ABI for x86_64 rather than a kernel / architecture. The Linux ABI includes the memory map, syscalling convention and data structures passed to / from th
by gnode 8y ago
It's an ABI for x86_64 rather than a kernel / architecture. The Linux ABI includes the memory map, syscalling convention and data structures passed to / from the kernel.
For a start, the kernel sets up virtual memory with stack at the high addresses, which would be out of reach for 32-bit pointers (without translation). Secondly, pointers passed to the kernel would have to be converted to 64-bit and vice versa.
Conceivably, you could remap your virtual address space to have a stack and libraries within the 32-bit space, and then jump into x32-like code which translated pointers to and from 64-bit for syscalls and kernel data structures. This would retain most of the benefits of x32 for CPU-bound processes.
- geocar 8y ago> Conceivably, you could remap your virtual address space to have a stack and libraries within the 32-bit space, and then jump into x32-like code which translated pointers to and from 64-bit for syscalls and kernel data structures. This would retain most of the benefits of x32 for CPU-bound processes. That's what I'm thinking about. You'd need a little cooperation from libc and the dynamic linker in order to have a good "user" experience, and I think you can even share 64-bit libs (provided they don't call mmap() themselves and return the pointer to your application), but these seem almost manageable.