4 ms·

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

• nwmcsween 8y ago
  What? How would MAP_32BIT reimplement an entire ABI? It has more in common with x86-64 than i386.
  • rocqua 8y ago
    From a very cursory look, it seems like it doesn't. Based on the man page for mmap [1], it seems like all MAP_32BIT does is ensure that memory is allocated in the lower 2GB of addresses. 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. http://man7.org/linux/man-pages/man2/mmap.2.html http://man7.org/linux/man-pages/man2/mmap.2.html
    • syn0byte 8y ago
      You can easily truncate or pad to convert between 64-32bit as long as the 64bit end stays in the lower 2GB. 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...
  • geocar 8y ago
    x32 isn't i386. It's x86_64 with truncated pointers. 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.
    • AstralStorm 8y ago
      But the offset still is 64bit right? (As per large file support)
      • walkingolof 8y ago
        Depends, the offset is a size_t, i.e. and unsigned integer, so if you compile the program as a 64 bit binary, its 64 bit, 32 bit otherwise.
      • jabl 8y ago
        X32 has it's own (partial) set of syscalls. Similar to how a x86-64 kernel ran run traditional x86-32 code. 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.
• alexlarsson 8y ago
  There was never a x32 kernel, it always ran on x86_64 kernels. x32 is just a userspace ABI.
• 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.