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: MI: type prefixes for values



On Feb 20, 2006, at 10:51 PM, Vladimir Prus wrote:


On Monday 20 February 2006 21:58, Jim Ingham wrote:
Making variable objects is always slower than just printing the
values if you are only doing it one time.  The variable objects don't
do any magic to get their values - they go through the same code as
"print" does ultimately, but they do a little more work getting
there.  The overhead is not all that great, however.  Just malloc'ing
some data structures and inserting them into a list somewhere.

The advantage of variable objects is that they cache the parsed
expression.  So the second & third etc. evaluation is much faster.
This is a pretty common usage pattern, especially with local
variables, since you usually step a number of times in any given
frame, and the locals all have to be updated with each step.  The
variable objects have some other convenient features, like the -var-
update command which refreshes the values will report only the
variable objects whose values have changed, so the front end has to
fetch less data.

Say, I've created a bunch of variable objects for for local variables. When I
leave the function, those variables become invalid. How do you detect this
case? Do you have a command '-list-var-objects-that-are-dead', or some other
mechanism.

We don't do this in gdb. Xcode keeps track of which varobj's go with which stack frames, and deletes them when appropriate. You want to be a little clever about this, 'cause there's no need to delete the varobj's till the function is actually popped off the stack. You might descend into another function then come back to this one, in which case the varobj's are still good.


Note, however, that the varobj's do remember their frames, so if you tried to evaluate one that was no longer on the stack, the varobj would report "out of scope".


We also added the option to return all the locals in all the blocks
in a function.  This allows you to present all the variables, and
then mark the ones which are not currently in scope appropriately.  I
find this less confusing than having the contents of the variables
window come and go as you step through the function.  Most of our
users seem to agree.

Heck, such a feature will immediately fix:


http://bugs.kde.org/show_bug.cgi?id=120439

Is this patch available on some branch in the public CVS repository?

No, it is just in the Apple sources. You can get these from the apple opensource repository:


cvs -d pserver:anonymous@anoncvs.opensource.apple.com:/cvs/root co gdb

Our current TOT was last sync'ed up with the FSF sources about 6 months ago. Note, however, that in the area of variable objects, our sources are substantially different from the FSF sources.

Jim



- Volodya


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