Date: Wed, 18 Feb 2009 09:27:44 +0200 From: Jordan Gordeev <jgordeev@dir.bg> To: Peter Jeremy <peterjeremy@optushome.com.au> Cc: freebsd-amd64@freebsd.org Subject: Re: 32-bit truncation of 64-bit values Message-ID: <499BB870.9060801@dir.bg> In-Reply-To: <20090217190106.GB1351@server.vk2pj.dyndns.org> References: <20090217190106.GB1351@server.vk2pj.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?499BB870.9060801>