From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1113 invoked by alias); 6 Apr 2006 13:35:52 -0000 Received: (qmail 1105 invoked by uid 22791); 6 Apr 2006 13:35:52 -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; Thu, 06 Apr 2006 13:35:51 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1FRUeI-0006a4-Qb; Thu, 06 Apr 2006 09:35:46 -0400 Date: Thu, 06 Apr 2006 13:45:00 -0000 From: Daniel Jacobowitz To: Vladimir Prus Cc: Jim Ingham , GDB List Subject: Re: MI: type prefixes for values Message-ID: <20060406133546.GB25088@nevyn.them.org> Mail-Followup-To: Vladimir Prus , Jim Ingham , GDB List References: <200602171724.03824.ghost@cs.msu.su> <200602210951.53705.ghost@cs.msu.su> <8B18ED72-F372-4A1C-A6DF-9A5AA4A0826F@apple.com> <200604061703.26246.ghost@cs.msu.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200604061703.26246.ghost@cs.msu.su> 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/msg00058.txt.bz2 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. > > 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. -- Daniel Jacobowitz CodeSourcery