From: Vladimir Prus <ghost@cs.msu.su>
To: Jim Ingham <jingham@apple.com>
Cc: GDB List <gdb@sources.redhat.com>
Subject: Re: MI: type prefixes for values
Date: Thu, 06 Apr 2006 13:33:00 -0000 [thread overview]
Message-ID: <200604061703.26246.ghost@cs.msu.su> (raw)
In-Reply-To: <8B18ED72-F372-4A1C-A6DF-9A5AA4A0826F@apple.com>
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
> > detect this
> > case? Do you have a command '-list-var-objects-that-are-dead', or
> > some other
> > mechanism.
>
> 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 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?
> 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.
- Volodya
next prev parent reply other threads:[~2006-04-06 13:03 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-17 9:09 Vladimir Prus
2006-02-17 10:22 ` Eli Zaretskii
2006-02-17 10:29 ` Vladimir Prus
2006-02-17 11:26 ` Eli Zaretskii
[not found] ` <200602171450.16858.ghost@cs.msu.su>
2006-02-17 13:49 ` Eli Zaretskii
2006-02-17 13:54 ` Daniel Jacobowitz
2006-02-17 14:08 ` Eli Zaretskii
2006-02-17 13:58 ` Vladimir Prus
2006-02-17 14:11 ` Eli Zaretskii
2006-02-17 14:26 ` Vladimir Prus
2006-02-17 14:36 ` Bob Rossi
2006-02-17 14:43 ` Vladimir Prus
2006-02-17 14:51 ` Bob Rossi
2006-02-17 15:02 ` Vladimir Prus
2006-02-17 19:25 ` Eli Zaretskii
2006-02-17 19:33 ` Daniel Jacobowitz
2006-02-17 19:36 ` Eli Zaretskii
2006-02-17 19:38 ` Daniel Jacobowitz
2006-02-17 19:56 ` Eli Zaretskii
2006-02-17 20:05 ` Bob Rossi
2006-02-17 20:07 ` Eli Zaretskii
2006-02-17 20:17 ` Daniel Jacobowitz
2006-02-17 20:28 ` Eli Zaretskii
2006-02-17 20:33 ` Daniel Jacobowitz
2006-02-17 21:14 ` Jim Ingham
2006-02-18 11:34 ` Eli Zaretskii
2006-02-20 13:47 ` Vladimir Prus
2006-02-20 8:11 ` Vladimir Prus
2006-02-20 19:49 ` Jim Ingham
2006-02-20 20:56 ` Daniel Jacobowitz
2006-02-20 20:57 ` Jim Ingham
2006-02-21 14:15 ` Vladimir Prus
2006-02-21 21:33 ` Jim Ingham
2006-04-06 13:33 ` Vladimir Prus [this message]
2006-04-06 13:45 ` Daniel Jacobowitz
2006-04-06 14:05 ` Vladimir Prus
2006-04-06 14:31 ` Daniel Jacobowitz
2006-04-06 15:05 ` Vladimir Prus
2006-04-06 15:32 ` Daniel Jacobowitz
2006-04-06 18:53 ` Jim Ingham
2006-04-06 16:49 ` Jim Ingham
2006-04-06 16:49 ` Daniel Jacobowitz
2006-04-06 16:52 ` Jim Ingham
2006-04-06 18:58 ` Jim Ingham
2006-04-07 8:13 ` Vladimir Prus
2006-04-07 20:08 ` Jim Ingham
2006-04-12 15:38 ` Vladimir Prus
2006-04-12 19:41 ` Jim Ingham
2006-04-13 16:15 ` Vladimir Prus
2006-02-17 21:19 ` Daniel Jacobowitz
2006-02-17 20:20 ` Bob Rossi
2006-02-17 20:47 ` Daniel Jacobowitz
2006-02-17 19:44 ` Bob Rossi
2006-02-17 19:59 ` Eli Zaretskii
2006-02-20 7:28 ` Vladimir Prus
2006-02-20 23:37 ` Eli Zaretskii
2006-02-21 4:13 ` Daniel Jacobowitz
2006-02-21 14:15 ` Vladimir Prus
2006-02-21 20:41 ` Daniel Jacobowitz
2006-02-20 13:48 ` Vladimir Prus
2006-02-17 11:27 ` Nick Roberts
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200604061703.26246.ghost@cs.msu.su \
--to=ghost@cs.msu.su \
--cc=gdb@sources.redhat.com \
--cc=jingham@apple.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox