From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25512 invoked by alias); 17 Apr 2006 07:16:58 -0000 Received: (qmail 25504 invoked by uid 22791); 17 Apr 2006 07:16:58 -0000 X-Spam-Check-By: sourceware.org Received: from romy.inter.net.il (HELO romy.inter.net.il) (192.114.186.66) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 17 Apr 2006 07:16:57 +0000 Received: from HOME-C4E4A596F7 (IGLD-80-230-11-227.inter.net.il [80.230.11.227]) by romy.inter.net.il (MOS 3.7.3-GA) with ESMTP id DZN06349 (AUTH halo1); Mon, 17 Apr 2006 10:16:40 +0300 (IDT) Date: Mon, 17 Apr 2006 07:38:00 -0000 Message-Id: From: Eli Zaretskii To: Mark Kettenis , gdb@sources.redhat.com CC: nickrob@snap.net.nz In-reply-to: <20060417013343.GA4114@nevyn.them.org> (message from Daniel Jacobowitz on Sun, 16 Apr 2006 21:33:43 -0400) Subject: Re: info frame Reply-to: Eli Zaretskii 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> 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/msg00228.txt.bz2 > 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?