From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12338 invoked by alias); 25 May 2005 03:51: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 12330 invoked by uid 22791); 25 May 2005 03:51:29 -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 03:51:29 +0000 Received: from farnswood.snap.net.nz (p176-tnt1.snap.net.nz [202.124.110.176]) by viper.snap.net.nz (Postfix) with ESMTP id 92EC153748D; Wed, 25 May 2005 15:51:26 +1200 (NZST) Received: by farnswood.snap.net.nz (Postfix, from userid 501) id 64DFA62A99; Wed, 25 May 2005 04:52:48 +0100 (BST) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17043.63119.670138.172271@farnswood.snap.net.nz> Date: Wed, 25 May 2005 03:51:00 -0000 To: Daniel Jacobowitz Cc: gdb@sources.redhat.com Subject: Re: Consistent format for memory addresses In-Reply-To: <20050525033745.GA25868@nevyn.them.org> References: <17043.61074.262608.156551@farnswood.snap.net.nz> <20050525033745.GA25868@nevyn.them.org> X-SW-Source: 2005-05/txt/msg00310.txt.bz2 > > However "info frame" gives: > > > > (gdb) info frame > > Stack level 0, frame at 0xbffff730: > > eip = 0x80484d9 in main (myprog.c:55); saved eip 0x4006015a > > ^^^^^^^^^ > > > > Still seven digits. The human mind adjusts easily to such differences, but > > front ends---or at least the one I'm writing for Emacs---don't. > > I have no objection - but is it really that hard to treat it as a > number? 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. I know the answer is GDB/MI but I'm (still!) hoping to get one release of Emacs out using annotations. I don't know the logic behind the change in disassemble but my concern is that it will mean that others like "info frame" will change at some unspecified time in the future. I realise that I have to expect CLI output to move forward, I'm just trying to ensure it happens in a co-ordinated manner. Nick