Re: -var-update and address changes

[Jim Ingham <jingham@apple.com>]

On Apr 13, 2006, at 1:26 AM, Vladimir Prus wrote:

> Jim Ingham wrote:
>
>
>>> So, the only solution is to remove all varobjs, and create them
>>> afresh,
>>> which is contrary to the very purpose of varobjs.
>>>
>>> Can somebody suggest the right fix? So far, I think that the  
>>> simplest
>>> approach is to make gdb print stack address of current frame, like
>>> is done
>>> on the Apple branch:
>>>
>>>      553^done,stack=[frame=
>>>      {level="0",addr="0x00003db0",fp="0xbffff2c0",......
>>>
>>> That way, frontend can deal with the issue of frame stacks
>>> themself, and
>>> -var-update will be only used when single-stepping inside a given
>>> frame.
>>> Will patches to implement this be welcome?
>>
>> That's what I would suggest.  It seemed the simplest way to handle
>> this when we were first thinking about it.
>
> FWIW, I've imp^H^H^Hkluged this by parsing the output of "info frame"
> command. This gets me full frame id, but this should really be  
> inside MI.
>
>>> And I still don't know what to do about variable shadowing inside a
>>> single
>>> function.
>>
>> I added another option to -stack-list-locals to print all the blocks
>> in a given function.  Using this plus the option to have -stack-list-
>> locals return variable object, you will get all the shadowed
>> variables in the function as varobj's when you enter the function.
>> Then the varobj system will tell you which of these are in and out of
>> scope at any given PC.
>
> You mean, using -var-update and the "in_scope" attribute?

Yes, -var-update will list as changed any varobj that has come into  
or out of scope since the last -var-update.

>
>> This all works in our branch if you want to see one example of how to
>> do it.
>
> Unfortunately, last time I tried it did not build on Linux.

Sorry 'bout that.  We only ever build it on Mac OS X.

Jim