7 ms·
What? How would MAP_32BIT reimplement an entire ABI? It has more in common with x86-64 than i386.
by nwmcsween 8y ago
What? How would MAP_32BIT reimplement an entire ABI? It has more in common with x86-64 than i386.
- rocqua 8y agoFrom 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 agoYou 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 agox32 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 agoBut the offset still is 64bit right? (As per large file support)
- walkingolof 8y agoDepends, 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 agoX32 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.