From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6381 invoked by alias); 17 Apr 2006 01:33:51 -0000 Received: (qmail 6373 invoked by uid 22791); 17 Apr 2006 01:33:50 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Mon, 17 Apr 2006 01:33:49 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1FVIcZ-00015A-VG; Sun, 16 Apr 2006 21:33:44 -0400 Date: Mon, 17 Apr 2006 05:57:00 -0000 From: Daniel Jacobowitz To: Nick Roberts Cc: Mark Kettenis , gdb@sources.redhat.com Subject: Re: info frame Message-ID: <20060417013343.GA4114@nevyn.them.org> Mail-Followup-To: Nick Roberts , Mark Kettenis , gdb@sources.redhat.com References: <17474.53281.404673.189792@farnswood.snap.net.nz> <200604162333.k3GNXLeX004661@elgar.sibelius.xs4all.nl> <17474.58179.83052.362944@farnswood.snap.net.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17474.58179.83052.362944@farnswood.snap.net.nz> User-Agent: Mutt/1.5.8i X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-04/txt/msg00222.txt.bz2 On Mon, Apr 17, 2006 at 12:37:23PM +1200, Nick Roberts wrote: > Does this mean that if we choose to print the frame address in MI as part > of the output of -stack-list-frames: > > >> Can somebody suggest the right fix? So far, I think that the simplest > >> approach is to make gdb print stack address of current frame, like > >> is done > >> on the Apple branch: > >> > >> 553^done,stack=[frame= > >> {level="0",addr="0x00003db0",fp="0xbffff2c0",...... > > 0xbffff2c0 should not be the value of $fp but the value of "frame at..." in > 'info frame`? In fact, it's like that it will be the "frame at" address. But I don't think it would be wise to architect that into the interface; I think I explained why earlier, but if not, it's because this is a touchy internal interface for GDB. If you want to display it to the user, you might want something different - either explicitly the $sp, or explictly the architectural $fp register, or explicitly the call frame address. If you want to use it in a frontend, then all we should offer is an opaque ID for equality testing, IMHO. If GDB changes its internal representation we shouldn't have to update frontends. -- Daniel Jacobowitz CodeSourcery