From owner-freebsd-amd64@FreeBSD.ORG Wed Feb 18 07:57:58 2009 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B973106564A for ; Wed, 18 Feb 2009 07:57:58 +0000 (UTC) (envelope-from jgordeev@dir.bg) Received: from dir.bg (mail.dir.bg [194.145.63.28]) by mx1.freebsd.org (Postfix) with ESMTP id 9ECC78FC15 for ; Wed, 18 Feb 2009 07:57:56 +0000 (UTC) (envelope-from jgordeev@dir.bg) Received: from [84.238.192.16] (account jgordeev@dir.bg [84.238.192.16] verified) by srv.dir.bg (CommuniGate Pro SMTP 5.2.12) with ESMTPSA id 67256522; Wed, 18 Feb 2009 09:27:53 +0200 Message-ID: <499BB870.9060801@dir.bg> Date: Wed, 18 Feb 2009 09:27:44 +0200 From: Jordan Gordeev User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20070606 X-Accept-Language: bg, en MIME-Version: 1.0 To: Peter Jeremy References: <20090217190106.GB1351@server.vk2pj.dyndns.org> In-Reply-To: <20090217190106.GB1351@server.vk2pj.dyndns.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-amd64@freebsd.org Subject: Re: 32-bit truncation of 64-bit values X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 07:57:58 -0000 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.