From: Jim Blandy <jimb@codesourcery.com>
To: gdb@sourceware.org
Subject: Questions about MI variable objects
Date: Thu, 24 May 2007 22:17:00 -0000 [thread overview]
Message-ID: <m3lkfdhnnt.fsf@codesourcery.com> (raw)
I have some questions for GUI implementors. Suppose I have the
following program:
void
foo (int x)
{
if (x > 0)
foo (x - 1);
}
void
bar (int x)
{
foo (x - 1);
}
int
main (int argc, char **argv)
{
foo (2);
bar (10);
return 0;
}
Suppose I'm stopped where the stack is like this:
main -> foo (2) -> foo (1) -> foo (0)
Suppose the top frame is selected, and the user adds a display for
'x'. Clearly, it should show '0'.
These are questions about what the GUI should display --- not what GDB
or MI or varobjs should do. They're about what you want the user to
see.
1) If the user selects the 'foo (1)' frame, what should happen to the
display of 'x'? Should it grey out? Should it now show 1? (I'd
say it should show 1.)
2) If the user lets the 'foo (0)' call run to completion (as with a
GDB CLI 'finish' command), what should happen to the display of
'x'? Should it disappear altogether? Should it grey out? Should
it show 1? (I'd say it should show 1.)
3) If the user lets control go all the way back to main, what should
happen to the display? (I'd say it should grey out.)
4) If the user lets control run to 'foo' again, so the stack now looks
like:
main -> bar (10) -> foo (9)
what should happen to the display of 'x'? (I'd say it should show
'9'.)
If there's some general agreement on how these ought to behave (not
necessarily my guesses, just any agreement) then maybe we could make
MI varobjs match that behavior, so that each GUI variable display
could be backed by exactly one varobj, and GDB's reports on changes to
the varobj's state would correspond closely to changes in the GUI's
display. Varobjs exist to help GUIs, and GDB shouldn't be making GUIs
jump through hoops to get the behavior they want.
The principle behind my guesses is that a display should refer to a
particular variable in the source code --- a particular declaration
--- and should show its value whenever that declaration is in scope in
the selected frame. This is less specific than having the display
refer to a particular frame's instance of that variable, and more
specific than having it refer to any variable that happens to be in
scope under that name. But it's what I'd expect from a GUI.
At the moment, GDB tries to associate each varobj with a specific
function invocation. It's so easy to concoct a case where frame ID's
collide that in casual testing, the varobj code may appear to
implement something more like my suggested behavior. But it doesn't.
next reply other threads:[~2007-05-24 22:17 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-24 22:17 Jim Blandy [this message]
2007-05-25 3:35 ` Nick Roberts
2007-05-25 18:13 ` Jim Blandy
2007-05-26 2:29 ` Nick Roberts
2007-05-25 8:32 ` Vladimir Prus
2007-05-25 18:11 ` Jim Blandy
2007-05-25 18:42 ` Jim Ingham
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=m3lkfdhnnt.fsf@codesourcery.com \
--to=jimb@codesourcery.com \
--cc=gdb@sourceware.org \
/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