Re: Understanding GDB frames

[Jim Blandy <jimb@codesourcery.com>]

Ross Morley <ross@tensilica.com> writes:
>>> 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 :-)
>>>
>>>  
>>>
>> seems to be an unambiguous "no".
>>
>> This begs the question: when should GDB destroy a varobj?
>
> I need to revisit this. It's not clear that GDB destroys a varobj
> at all unless the GUI tells it to. It seems GDB tells the GUI the
> varobj went out of scope, and the GUI then doesn't update it. The
> GUI's concept of scope is different than the language concept. A
> var is considered in_scope if an instance of its function exists in
> the stack frame (*). So perhaps GDB should not say it's not in_scope
> if any instance of it still exists, even if it's a different instance
> than when the varobj was created. That is, the frame ID should not
> determine whether a varobj is in_scope for MI. A mere search of the
> frame stack for any frame with the same entrypoint (same function)
> should indicate in_scope.
>
> (*) Before GDB 6 and the new frame ID, it seems varobj.c looked
>    for the frame address still being in the stack. So it may be
>    that MI considers a var "in scope" if its function is still
>    on the stack at the same level, but not if it's at a different
>    level. This seems less ideal for the GUI but is what GDB achieves
>    when frame ID uses only stack ptr and PC at function entry.
>
> To avoid possibly breaking assumptions made by MI clients, it might
> be best to simply require that a gdbarch compute frame IDs based
> only on frame location in stack(s) and function entrypoint (and
> explicitly NOT try to make frame ID represent a unique instantiation
> of a function). This requires no change to generic GDB. If GUI people
> think it would provide better behavior and can ensure their GUIs don't
> rely on the present behavior, GDB could in future relax its in_scope
> determination for MI vars.

Well, GDB uses frame IDs itself in many different ways, not just for
MI.  Frame IDs are the only thing in GDB that can represent a frame
from one program pause to the next.  So they're used to implement
'next', 'finish', and so on.  For those purposes, frame IDs need to be
as precise as is practical.  If we could, we'd give every frame ever
pushed a unique ID.  We need to work out how to get the behavior GUIs
want from varobjs in terms of those ideal frame IDs.

Varobjs are really just little bits of GUI state living inside of GDB,
for speed.  GDB's job is to keep the GUI up to date on how the GUI's
varobjs relate to the program's current state.  I don't think GDB
should ever delete a varobj itself, except perhaps by prior
arrangement with the GUI, for the GUI's convenience.

I'd expect the most common use is for varobjs to correspond to GUI
expression/variable displays, where the user adds and removes entries.
In this use case, having GDB ever delete varobjs is just a pain: the
GUI wants them to stick around until some instance of the variable
comes back into scope.  It's unclear what should happen as the program
runs and as the user selects different frames; I have some questions
about that that I'll post separately.