From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4753 invoked by alias); 17 Apr 2006 07:38:41 -0000 Received: (qmail 4732 invoked by uid 22791); 17 Apr 2006 07:38:40 -0000 X-Spam-Check-By: sourceware.org Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 17 Apr 2006 07:38:39 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1FVOJa-0001hM-4q for gdb@sources.redhat.com; Mon, 17 Apr 2006 09:38:30 +0200 Received: from zigzag.lvk.cs.msu.su ([158.250.17.23]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 17 Apr 2006 09:38:30 +0200 Received: from ghost by zigzag.lvk.cs.msu.su with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 17 Apr 2006 09:38:30 +0200 To: gdb@sources.redhat.com From: Vladimir Prus Subject: Re: info frame Date: Mon, 17 Apr 2006 08:41:00 -0000 Message-ID: References: <17474.53281.404673.189792@farnswood.snap.net.nz> <200604162333.k3GNXLeX004661@elgar.sibelius.xs4all.nl> <17474.58179.83052.362944@farnswood.snap.net.nz> <20060417013343.GA4114@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit User-Agent: KNode/0.8.2 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/msg00230.txt.bz2 Eli Zaretskii wrote: >> Date: Sun, 16 Apr 2006 21:33:43 -0400 >> From: Daniel Jacobowitz >> Cc: Mark Kettenis , gdb@sources.redhat.com >> >> > >> 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. > > Daniel, I cannot parse this sentence, and consequently I cannot figure > out what are you saying in general. > >> 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. > > Are you saying that the "frame at ..." part in the CLI output is > meaningless for users? If so, why do we show it at all? Well, "info frame" is documented to print absolutely all information about a frame. And frame base address is part of "all information". I would not want that field to go away, at least not until frame id is exposed via some other command. - Volodya