Re: Understanding GDB frames

[Jim Blandy <jimb@codesourcery.com>]

Daniel Jacobowitz <drow@false.org> writes:
> On Tue, May 22, 2007 at 11:32:41AM -0700, Jim Ingham wrote:
>> I don't see what the bad effect of not destroying the varobj if the frame id is 
>> identical is. You might get an errant "value changed" notification.  Other than 
>> that, I can't see what you would be gaining.
>> 
>> If we're going to do some extra work to make sure we mark variables out of 
>> scope when their frames are exited, we should get something real out of it.  So 
>> far it seems the benefit is only theoretical.
>
> Sure.  I'm not seriously proposing we do that extra work, though I did
> think about it.  But what we do need is to clarify our semantics so
> that front ends know what to expect.  Should varobjs be destroyed when
> we leave and re-enter a function?  If the answer is "maybe", then that
> is confusing enough to deserve some more explanation :-)

Varobjs were originally introduced to improve the performance of
GUI's.  If I remember right, the win came from reducing round trips,
and perhaps from avoiding reparsing expressions.  I think that's still
their reason for existence.

So varobjs should work in whatever way is most helpful for the GUIs
that use them.  Implementing behavior that seems clean at the GDB
level, but that makes GUIs do work that negates varobjs' original
advantages, is a step backwards.  Deleting varobjs when they go out of
scope, if the GUI wants to keep its display alive for the next time
that block comes back into scope, is unhelpful.

What behavior does Eclipse (say) want?

That is, if I add a variable 'x' to my display list, and the currently
selected frame is for a function 'f' with a local variable 'x', does
Eclipse want that display:

a) to be removed and forgotten when that particular frame is popped?

b) to be displayed and updated whenever a frame of 'f' is current, and
   greyed out otherwise?  (This is what you'd want if you were going
   through various hits of a breakpoint looking at 'x' to recognize the
   hit you care about.)

c) to just show whatever 'x' happens to be in scope in the current
   frame?

GDB's varobjs currently implement b), which is what I'd think most
GUIs would want:

$ cat vo.c
int
foo (int x)
{
  return x + 1;
}

int
bar (int x)
{
  return x;
}

int
main (int argc, char **argv)
{
  foo (10);
  foo (20);
  bar (30);

  return 0;
}

If I set breakpoints in foo and bar, run to the first hit in foo, and
create a varobj for x, then the varobj is marked:
- out of scope when I return to main,
- back in scope when I re-enter foo,
- out of scope when I return to main a second time, and 
- still out of scope when I enter bar.

So the frame argument to -var-create is used to identify a scope, not
to tie the varobj to that specific frame.  Which I think is the
behavior that makes life easiest for GUIs.