Re: Understanding GDB frames

[Ross Morley <ross@tensilica.com>]

Ross Morley wrote:

>
> So the answer to Daniel's question:
>
>> 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.

Ross