This is the mail archive of the
mailing list for the GDB project.
Re: MI: type prefixes for values
- From: Jim Ingham <jingham at apple dot com>
- To: Vladimir Prus <ghost at cs dot msu dot su>
- Cc: GDB List <gdb at sources dot redhat dot com>
- Date: Thu, 6 Apr 2006 09:53:06 -0700
- Subject: Re: MI: type prefixes for values
- References: <firstname.lastname@example.org> <email@example.com> <8B18ED72-F372-4A1C-A6DF-9A5AA4A0826F@apple.com> <firstname.lastname@example.org>
On Apr 6, 2006, at 6:03 AM, Vladimir Prus wrote:
On Tuesday 21 February 2006 21:13, Jim Ingham wrote:
Say, I've created a bunch of variable objects for for local
variables. When I
leave the function, those variables become invalid. How do you
case? Do you have a command '-list-var-objects-that-are-dead', or
We don't do this in gdb. Xcode keeps track of which varobj's go with
which stack frames, and deletes them when appropriate. You want to
be a little clever about this, 'cause there's no need to delete the
varobj's till the function is actually popped off the stack. You
might descend into another function then come back to this one, in
which case the varobj's are still good.
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
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
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
stack. How do you detect this case?
I said this in another response, but to be clear, Xcode stores the
frame_id's from each stack frame when it stops. It holds onto this,
and when it stops again it checks this fingerprint against the new
frame id's, and the throws away all the varobj's from the point the
frame_id's vary on to the bottom of stack. There's no ambiguity if
you do this.
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.