Re: MI: type prefixes for values

[Jim Ingham <jingham@apple.com>]

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