Re: Understanding GDB frames

Ross Morley
2007-05-24T00:05:38Z

Jim Blandy wrote:

>Ross Morley <ross@tensilica.com> writes:
>
>
>>We need to remember, though, that one goal is to minimize the overhead
>>for the MI front end of having to re-create varobjs. As we get better
>>at detecting a frame change (reduce false positives) we actually increase
>>the overhead for the FE because it then (to be correct) needs to recreate
>>its varobjs. We should think about solving that problem before we get too
>>much better at detecting frame changes.
>>
>>
>
>If you don't detect a frame change, then you're displaying garbage,
>aren't you?
>
You're displaying values from a different instance of the function.
The (new) frame is still used to find the values, but the varobj is
not deleted. Technically it's not the same variable, but from the
GUI perspective it's useful to consider it the same, as you described
in your previous post.

>I'd expect fewer false positives should always be good...
>
>
>
Apparently not if it comes at the price of having to recreate varobjs.

But it seems we're barking up the wrong tree in worrying about how to
detect a variable going out of scope...

I just had a long discussion with our eclipse GUI guy, Pete MacLiesh.
What the GUI wants is to be able to highlight which variables changed in
a function between one breakpoint and the next. It doesn't matter whether
we are still in the same instantiation of the function, in a completely
different one, or at a different frame level or recursion level.

The varobj should be associated strictly with the function, NOT the frame.
When its value is updated by -var-update, the frame is used only to find
the value (which, according to Pete, might change even as the user clicks
up and down the stack of a recursive function).

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?
Our initial conclusion is that it is probably best to do it only when
there are no longer any instances of the function on the stack. Frame ID
should not enter into this equation, so gdbarchs are free to implement
frame ID the way that is best for them, without unexpected consequences
for GUI FEs.

Now this requires GDB to walk the entire stack when a function associated
with a varobj disappears in order to know that it has disappeared. That is
a small overhead compared to the GUI having to re-create possibly dozens of
varobjs for many functions, and try to track changes in value independently
of GDB. The reason varobjs exist is to avoid that. GDB incurs the overhead
only for varobjs, so it does not affect non-MI performance, and performance
under MI needs to be considered in light of the entire package with the GUI.

I hope this is helpful.

Ross