From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5610 invoked by alias); 25 May 2005 21:10:55 -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 5591 invoked by uid 22791); 25 May 2005 21:10:47 -0000 Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.8) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Wed, 25 May 2005 21:10:47 +0000 Received: from farnswood.snap.net.nz (p141-tnt2.snap.net.nz [202.124.108.141]) by viper.snap.net.nz (Postfix) with ESMTP id D436653759E; Thu, 26 May 2005 09:10:43 +1200 (NZST) Received: by farnswood.snap.net.nz (Postfix, from userid 501) id D65F962A99; Wed, 25 May 2005 22:11:09 +0100 (BST) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17044.59885.202702.599140@farnswood.snap.net.nz> Date: Wed, 25 May 2005 21:10:00 -0000 To: Eli Zaretskii Cc: gdb@sources.redhat.com Subject: Re: Consistent format for memory addresses In-Reply-To: References: <17043.61074.262608.156551@farnswood.snap.net.nz> <20050525033745.GA25868@nevyn.them.org> <17043.63119.670138.172271@farnswood.snap.net.nz> X-SW-Source: 2005-05/txt/msg00326.txt.bz2 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. 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. Nick *** /home/nick/src/gdb/stack.c.~1.132.~ 2005-05-18 20:17:24.000000000 +1200 --- /home/nick/src/gdb/stack.c 2005-05-26 09:09:17.000000000 +1200 *************** *** 958,964 **** printf_filtered (":\n"); } printf_filtered (" %s = ", pc_regname); ! deprecated_print_address_numeric (get_frame_pc (fi), 1, gdb_stdout); wrap_here (" "); if (funname) --- 958,964 ---- printf_filtered (":\n"); } printf_filtered (" %s = ", pc_regname); ! ui_out_field_core_addr (uiout, "addr", get_frame_pc (fi)); wrap_here (" "); if (funname)