32-bit truncation of 64-bit values
Jordan Gordeev
jgordeev at dir.bg
Tue Feb 17 23:57:58 PST 2009
Peter Jeremy wrote:
>Having just tracked down an issue caused by a pointer-to-int
>truncation, it occurs to me that it might be "instructive" to change
>the amd64 memory map so that the botton 4GB of address-space was
>unmapped by default (ie code, data, bss, stack and mmap all default to
>above 4GB). I notice that the process space layout has already
>changed since 7.x was branched (at least the same executable runs on
>7.x and SEGVs on -current due to a truncated pointer) and making
>this change might reveal more broken code.
>
>Given how close we are to 8.0, this might need to wait until after
>8 is branched.
>
>
>
My understanding is that implementing this idea is impossible.
The AMD64 ABI (available at
http://www.x86-64.org/documentation/abi-0.99.pdf) describes several
"code models": small, medium, large + some more.
The most popular is the small memory model, which prescribes that both
code and data fit into the first 2 GB of virtual address space. The
medium code model lifts this limitation for data, but preserves it for
text. The large memory model is of theoretical significance, in my
opinion, and I'm not sure gcc even implements it.
So, unless FreeBSD starts using its own amd64 ABI, or we start playing
with unpopular (and slower) memory models, I don't see how the otherwise
nice idea can be implemented.
More information about the freebsd-amd64
mailing list