From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15198 invoked by alias); 15 Feb 2011 18:59:16 -0000 Received: (qmail 15189 invoked by uid 22791); 15 Feb 2011 18:59: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 mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 15 Feb 2011 18:59:11 +0000 Received: (qmail 18109 invoked from network); 15 Feb 2011 18:59:09 -0000 Received: from unknown (HELO scottsdale.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 15 Feb 2011 18:59:09 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: [unavailable values part 1, 03/17] expose list of available ranges to common code Date: Tue, 15 Feb 2011 19:14:00 -0000 User-Agent: KMail/1.13.5 (Linux/2.6.35-25-generic; KDE/4.6.0; x86_64; ; ) Cc: Jan Kratochvil References: <201102071429.19096.pedro@codesourcery.com> <201102141939.10946.pedro@codesourcery.com> <20110214211223.GA9425@host1.dyn.jankratochvil.net> In-Reply-To: <20110214211223.GA9425@host1.dyn.jankratochvil.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201102151859.03901.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2011-02/txt/msg00334.txt.bz2 On Tuesday 15 February 2011 21:12:23, Jan Kratochvil wrote: > On Mon, 14 Feb 2011 20:39:10 +0100, Pedro Alves wrote: > > On Monday 14 February 2011 11:59:39, Jan Kratochvil wrote: > > > > +struct mem_range > > > > +{ > > > > + /* Lowest address in the range. */ > > > > + CORE_ADDR start; > > > > + > > > > + /* Length of the range. */ > > > > + int length; > > > > +}; > > > > > > Why couldn't GDB become 64bit clean - that is CORE_ADDR length. > > > > Probably a leftover from the value ranges stuff (value lengths > > are ints, and so I made the value range lengths be ints too). > > But I disagree with making it a CORE_ADDR. I think > > lengths should be LONGEST or ULONGEST. > > While ULONGEST should work due to this invariant: > ULONGEST_MAX >= CORE_ADDR_MAX > > Still in which case an inferior object size does not fit in CORE_ADDR? > I do not think it can happen, CORE_ADDR should be OK for inferior size_t. It's (mainly) not about fitting. An address is fundamently not the same as a length/size. Representing a size with a type meant for addresses is just not right, IMO. Imagine if CORE_ADDR was a C++ object that also included a reference to an address space (I'm not saying it should, only that it could. Even today you have the ppc/cell gdb using special bit hacks in CORE_ADDRs to represent address spaces). Then it would be clear that using it for lengths/sizes wasn't right. Just as size_t should be used for host sizes, and uintptr_t/intptr_t/pointers for host addresses. The opposite of what you said is actually quite possible. There are systems where the addressable address space is wider than the size of a single object/array can be (thus size_t bitwidth may be narrower than than of uintptr_t). As for what type for use then instead of CORE_ADDR, we traditionaly use LONGEST/ULONGEST throughout, AFAICS. I guess nobody ever saw a real need to come up with a special type for it. OOC, I did: $ grep "CORE_ADDR len" * -rn python/py-inferior.c:63: CORE_ADDR length; And I'm going to claim that this only hit shouldn't be using CORE_ADDR. Grepping for "LONGEST len" actually finds a large number of uses. -- Pedro Alves