This is the mail archive of the
mailing list for the GDB project.
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
case? Do you have a command '-list-var-objects-that-are-dead', or
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:
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:firstname.lastname@example.org:/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.