From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5515 invoked by alias); 26 May 2005 03:46:35 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 5492 invoked by uid 22791); 26 May 2005 03:46:32 -0000 Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Thu, 26 May 2005 03:46:32 +0000 Received: from drow by nevyn.them.org with local (Exim 4.50) id 1Db9KG-0006vX-V8; Wed, 25 May 2005 23:46:29 -0400 Date: Thu, 26 May 2005 03:46:00 -0000 From: Daniel Jacobowitz To: Eli Zaretskii Cc: Nick Roberts , gdb@sources.redhat.com Subject: Re: Consistent format for memory addresses Message-ID: <20050526034628.GA26565@nevyn.them.org> Mail-Followup-To: Eli Zaretskii , Nick Roberts , gdb@sources.redhat.com References: <17043.61074.262608.156551@farnswood.snap.net.nz> <20050525033745.GA25868@nevyn.them.org> <17043.63119.670138.172271@farnswood.snap.net.nz> <17044.59885.202702.599140@farnswood.snap.net.nz> <20050525212813.GA18065@nevyn.them.org> <17045.1379.28193.987032@farnswood.snap.net.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.8i X-SW-Source: 2005-05/txt/msg00332.txt.bz2 On Thu, May 26, 2005 at 06:39:51AM +0300, Eli Zaretskii wrote: > Well, it's a number, right? What else can possibly change in the > address format that leaves the numeric value unmodified? The only > other thing, besides leading zeros, that I can think of is sign > extension in some weird 32/64 bit situations. But that's a theory, I > don't even know if it's possible in practice. So I'd say leading > zeros is all you need to worry about for now. For the record it is possible in practice - this happens a lot on GDB for MIPS. However GDB should generally be consistent in this case about whether the leading bits are displayed, and in _that_ case, inconsistency is usually a bug. -- Daniel Jacobowitz CodeSourcery, LLC