Re: Questions about MI variable objects

[Vladimir Prus <ghost@cs.msu.su>]

Jim Blandy wrote:

> 
> 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'.

You're using an ill-defined term "adds a display". 

> 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.)

Assuming "adds a display" means "asked GUI to show the current value of 'x'
in the current scope now and in future", then clearly '1' should be shown.

> 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.)

Likewise.

> 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.)

Yes, 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'.)

I agree.

I think that @-variable-object should behave as described above.

Note also that it's possible to imagine GUI commands that show a
value of some expression in particular "scope", and became
forever grayed out when that scope dies. It raises numerous
questions how to identify scopes. It should be noted that KDevelop
does not have such UI command, and it was never requested.

> 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.

As I say, @-varobjs are supposed to act like this.

> 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.

This seem to contradict your claim that in 'bar', we should show '9'
for 'x' -- it's different 'x', after all. 

Assume user asked to show value of "x+y". There are three alternatives:

1. Show value of that expression in specific frame, gray it out
otherwise.
2. Show value of that expression in current frame, provided "x" and "y"
refer to the same language declaration.
3. Show value of that expression in current frame.

(3) is what implemented by @-varobjs. You seem to propose (2),
which will only differ from (2) by the fact that sometimes (3) will show
a value and (2) will have value greyed. Is this big enough deal to
worry about?

As for (1), it's implemented by ordinary varobjs. 

- Volodya