From owner-freebsd-amd64@FreeBSD.ORG Tue Feb 17 20:07:13 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 32A60106566B for ; Tue, 17 Feb 2009 20:07:13 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout021.mac.com (asmtpout021.mac.com [17.148.16.96]) by mx1.freebsd.org (Postfix) with ESMTP id 1F2318FC16 for ; Tue, 17 Feb 2009 20:07:13 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed Received: from hsheth-mbp.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp021.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0KF8001YD539MW10@asmtp021.mac.com> for freebsd-amd64@freebsd.org; Tue, 17 Feb 2009 11:06:46 -0800 (PST) Message-id: From: Marcel Moolenaar To: Peter Jeremy In-reply-to: <20090217190106.GB1351@server.vk2pj.dyndns.org> Date: Tue, 17 Feb 2009 11:06:45 -0800 References: <20090217190106.GB1351@server.vk2pj.dyndns.org> X-Mailer: Apple Mail (2.930.3) 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: Tue, 17 Feb 2009 20:07:13 -0000 On Feb 17, 2009, at 11:01 AM, 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. Use ia64 :-) On ia64 the upper 3 bits of the 64-bit pointer are used for the region (there are 8 obviously). Region 0 is reserved for 32-bit processes, so all native processes have pointers that can't fit in an int. This used to be a *very* big problem, but it has improved significantly. If you cannot run on ia64, at least try compiling on ia64. The compiler for ia64 is more sensitive about these things so you may be able to spot potential problems at compile time. FYI, -- Marcel Moolenaar xcllnt@mac.com