From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29386 invoked by alias); 15 Feb 2011 18:15:17 -0000 Received: (qmail 29371 invoked by uid 22791); 15 Feb 2011 18:15:16 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp2.caviumnetworks.com (HELO smtp2.caviumnetworks.com) (209.113.159.134) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 15 Feb 2011 18:15:12 +0000 Received: from caexch01.caveonetworks.com (Not Verified[192.168.16.9]) by smtp2.caviumnetworks.com with MailMarshal (v6,7,2,8378) id ; Tue, 15 Feb 2011 13:15:16 -0500 Received: from caexch01.caveonetworks.com ([192.168.16.9]) by caexch01.caveonetworks.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Feb 2011 10:15:08 -0800 Received: from dd1.caveonetworks.com ([12.108.191.236]) by caexch01.caveonetworks.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Feb 2011 10:15:08 -0800 Message-ID: <4D5AC2A6.10403@caviumnetworks.com> Date: Tue, 15 Feb 2011 18:15:00 -0000 From: David Daney User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Thunderbird/3.0.10 MIME-Version: 1.0 To: "Joseph S. Myers" CC: Joe Buck , Paul Koning , Matt Thomas , GCC , binutils , Prasun Kapoor Subject: Re: RFC: A new MIPS64 ABI References: <4D5990A4.2050308@caviumnetworks.com> <139B199E-0408-4F99-878C-D7063D607497@dell.com> <20110215021446.GE29824@synopsys.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org X-SW-Source: 2011-02/txt/msg00179.txt.bz2 On 02/15/2011 09:32 AM, Joseph S. Myers wrote: > On Mon, 14 Feb 2011, Joe Buck wrote: > >> On Mon, Feb 14, 2011 at 05:57:13PM -0800, Paul Koning wrote: >>> It seems that this proposal would benefit programs that need more than 2 GB but less than 4 GB, and for some reason really don't want 64 bit pointers. >>> >>> This seems like a microscopically small market segment. I can't see any sense in such an effort. >> >> I remember the RHEL hugemem patch being a big deal for lots of their >> customers, so a process could address the full 4GB instead of only 3GB >> on a 32-bit machine. If I recall correctly, upstream didn't want it >> (get a 64-bit machine!) but lots of paying customers clamored for it. >> >> (I personally don't have an opinion on whether it's worth bothering with). > > As I've been warning recently in the context of the "operator new[]" > overflow checks discussion, even if your process is addressing 4GB in such > circumstances it can't safely use single objects of 2GB or more and it's a > security problem when malloc/calloc/etc. allow such objects to be created. > See PR 45779. (There could well be issues with pointer comparisons as > well as pointer differences, although there at least it's possible to be > consistent if you don't allow objects to wrap around both in the middle > and at the end of the address space.) > Thanks Joseph, My idea for n32-big is that there would never be wraparound issues in the middle. The address space is contiguous from 0 to 4GB. Typically the area around the 4GB limit would be occupied by the stack and perhaps a several other regions reserved by the OS (vdso, etc. ). At the ends there could be wraparound/truncation issues, but this is no different than with the ABIs of most 32-bit targets. I don't know how hard it would be to make ptrdiff_t a signed 64-bit type. That would certainly complicate things somewhat. David Daney