From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13209 invoked by alias); 25 May 2005 21:28:51 -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 13087 invoked by uid 22791); 25 May 2005 21:28:20 -0000 Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Wed, 25 May 2005 21:28:20 +0000 Received: from drow by nevyn.them.org with local (Exim 4.50) id 1Db3QE-0004js-3c; Wed, 25 May 2005 17:28:14 -0400 Date: Wed, 25 May 2005 21:28:00 -0000 From: Daniel Jacobowitz To: Nick Roberts Cc: Eli Zaretskii , gdb@sources.redhat.com Subject: Re: Consistent format for memory addresses Message-ID: <20050525212813.GA18065@nevyn.them.org> Mail-Followup-To: Nick Roberts , Eli Zaretskii , 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17044.59885.202702.599140@farnswood.snap.net.nz> User-Agent: Mutt/1.5.8i X-SW-Source: 2005-05/txt/msg00327.txt.bz2 On Thu, May 26, 2005 at 09:11:09AM +1200, Nick Roberts wrote: > Eli Zaretskii writes: > > > From: Nick Roberts > > > Date: Wed, 25 May 2005 15:52:47 +1200 > > > Cc: gdb@sources.redhat.com > > > > > > In truth I don't mind seven or eight digits. What makes it difficult for me > > > is if the output of the CLI commands constantly change. > > > > But this (and similar) changes should not be very hard to accommodate > > for in Emacs, even if you search for the address as a string. For > > instance, you could use a regexp that allows for an arbitrary number > > of leading zeroes, right? > > > > Or am I missing something? > > Sure all differences can be accommodated if I know what the rules are. But as > Mark pointed out there are different systems. Presumably they might have > different rules. However, if the same function is used to print out all the > addresses, I don't need to know what format the address has. Since the output > address the two commands would be identical, I can simply record it from one > command and look for it in the other. You know it's a number - it's going to stay a number. A function to turn one hex number into a regular expression that would match it with leading zeros wouldn't be much work. > The discrepancy in the example I referred to arises because disassemble now > uses ui_out_field_core_addr while "info frame" still uses > deprecated_print_address_numeric. The deprecated prefix suggests that this > arrangement is not permanent. I would like to make changes now like the one > below. Clearly it would be sensible to change the other calls to > deprecated_print_address_numeric and, as it stands, it probably introduces a > memory leak and it might conflict with MI. However, I would like some > re-assurance that such a change would be accepted before going to the trouble > of providing a proper patch. The change is not correct. The ui_out_* output is considerably different in MI mode. I think paddr_nz will do what you want though. -- Daniel Jacobowitz CodeSourcery, LLC