RE: Understanding GDB frames

["Marc Gauthier" <marc@tensilica.com>]

Ross Morley wrote:
> Associating them with the function has problems with recursion. 
> It seems to
> me the ideal is to recreate vars that have gone out of scope (they really
> are new vars). Use of a scope breakpoint can better detect that than the
> current methods. However, are there implementation or performance issues?

As we discussed offline yesterday, this has performance implications
on the GUI, which would have to recreate the varobjs every time which
is time consuming.  One often wants to just set a breakpoint on a
function, and go "next - next - next - ..." across all invocations of
that function no matter where it's called from, looking at what variables
change until one reaches the desired invocation.  In this use mode one
doesn't care about specific frames, only about the specific function.
It's in this particular (common) use model that performance suffers
when distinguishing frame scopes.

It seems at the MI interface one wants a choice of whether a varobj
is associated with:
  (a) a specific frame (goes away when function returns)
  (b) a function
  (c) a function at the same depth (which some implement)

How the distinction is made at the GUI level is a separate question.
And what to do in the event of recursion when one selected a
function-level varobj (b) is also an interesting question -- perhaps
it always refers to the topmost instance (or to theseparately selected
instance if the currently selected stack depth is to that function).

That way, (b) and (c) have less performance impact, and one of them
could be the default.  And (a) being optional, could be fully supported
like watchpoints by setting a breakpoint at the return PC, even though
it has a performance hit (especially in the presence of recursion).

And perhaps MI docs could even document this  ;-)

-Marc