I read this as just dropping building an x32 kernel: It seems that mmap(MAP_32BIT) should continue to allow an x32 userspace (which is all I ever want anyway).
Does anyone have more details on this?
Does anyone have more details on this?
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.
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.
Notably, this means the actual pointers to that memory are still 64 bit.
Obviously, when you change pointers to be 32 bit, that requires an ABI change because the binary layout of your data structures is different.
You could do everything else in userspace if you really wanted. At the cost of safety, type handling and optimization from the compiler as all it would see is 64bit pointers being typecast and generic 32bit numeric data. Whatever you were looking to gain would be lost in extra work, and you can forget about debugging. But theoretically...
There aren't many syscalls that return pointers; mmap() is one of them, and using MAP_32BIT means that the pointer will be 32-bit.
32-bit code tells the kernel to allocate in the lower 32-bit address space (via MAP_32BIT) precisely so that the 64-bit pointers the kernel works with can be safely truncated to 32-bit user space pointers.