From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16626 invoked by alias); 6 Apr 2006 16:05:46 -0000 Received: (qmail 16617 invoked by uid 22791); 6 Apr 2006 16:05:45 -0000 X-Spam-Check-By: sourceware.org Received: from mail-out3.apple.com (HELO mail-out3.apple.com) (17.254.13.22) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 06 Apr 2006 16:05:41 +0000 Received: from relay8.apple.com (a17-128-113-38.apple.com [17.128.113.38]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id k36G5SXv009410; Thu, 6 Apr 2006 09:05:28 -0700 (PDT) Received: from [17.201.22.240] (inghji.apple.com [17.201.22.240]) by relay8.apple.com (Apple SCV relay) with ESMTP id 835DC5BB; Thu, 6 Apr 2006 09:05:28 -0700 (PDT) In-Reply-To: <200604061745.16585.ghost@cs.msu.su> References: <200602171724.03824.ghost@cs.msu.su> <200604061703.26246.ghost@cs.msu.su> <20060406133546.GB25088@nevyn.them.org> <200604061745.16585.ghost@cs.msu.su> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <08737C28-35FA-4938-978C-0055CC437B2F@apple.com> Cc: GDB List Content-Transfer-Encoding: 7bit From: Jim Ingham Subject: Re: MI: type prefixes for values Date: Thu, 06 Apr 2006 16:49:00 -0000 To: Vladimir Prus 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/msg00071.txt.bz2 On Apr 6, 2006, at 6:45 AM, Vladimir Prus wrote: > On Thursday 06 April 2006 17:35, Daniel Jacobowitz wrote: >> On Thu, Apr 06, 2006 at 05:03:25PM +0400, Vladimir Prus wrote: >>> I was thinking about this more, and still not 100% sure how Xcode >>> can do >>> this. Do you mean that Xcode takes a stack trace when the varobj was >>> created, and deletes varobj whenever it sees that stack became >>> shorter? >>> >>> The case I'm not sure about is this: >>> >>> 1. main calls 'a' which calls 'b' which bits breakpoint. >>> 2 varobj is created for local var of 'b' >>> 3. Users says 'continue'. >>> 4. 'b' exists and then 'a' calls 'b' again and breakpoint is >>> hit again. >>> >>> However, this second time it's not guaranteed that stack frame of >>> 'b' is >>> at the same address as it was the last time -- maybe 'a' has pushed >>> something on stack. How do you detect this case? >> >> Either b's stack frame is at the same address - in which case the >> varobj is still valid - or else it isn't, in which case the frame id >> has changed. > > I did not know that GDB exposes frame ID in any way, and Jim has > mentioned > that it's XCode that does the magic, not gdb. Is there some command > to print > frame id that I've missed? gdb does know what stack frame a variable is bound to. But gdb doesn't do any cleanup of variable objects on it's own. That's up to the MI client. I am pretty sure that is what I was referring to. > >>>> Note, however, that the varobj's do remember their frames, so if >>>> you >>>> tried to evaluate one that was no longer on the stack, the varobj >>>> would report "out of scope". >>> >>> Would be great to add this in FSF version. >> >> It's already there: >> >> /* The frame for this expression */ >> struct frame_id frame; >> >> c_value_of_root will always fail if the frame is gone. > > Sorry, does not seems to work this way here. For the following > program: > > void foo() > { > int i = 10; > ++i; > } > > int main() > { > foo(); > } > > I get this session: > > (gdb) > -break-insert a.cpp:5 > ^done,bkpt={...... > (gdb) > -exec-run > ^running > (gdb) > *stopped,reason="breakpoint-hit",frame= > {addr="0x080483a1",func="foo" > (gdb) > -var-create TMP * i > ^done,name="TMP",numchild="0",type="int" > (gdb) > -var-evaluate-expression TMP > ^done,value="10" > (gdb) > -exec-finish > ^running > (gdb) > *stopped,reason="function-finished",frame= > {addr="0x080483bd",func="main", > (gdb) > -var-evaluate-expression TMP > ^done,value="10" > (gdb) > > There's no indication that 'TMP' varobj belongs to the stack frame > we've > already left. This is with vanilla 6.4. > -var-evaluate-expression just fetches the data for the expression as it was last computed. As such, it doesn't know in or out of scope. It's -var-update, which recomputes the variable's value. So if you add on to your example: -var-update TMP ^done,changelist=[varobj={name="TMP",in_scope="false"}] This is for the Apple gdb, BTW, I don't have a Linux box handy so I'm not sure what the FSF gdb would print out, but the logic would be the same. Jim