This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Understanding GDB frames



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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]