Re: -var-update and address changes

[Vladimir Prus <ghost@cs.msu.su>]

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?

> 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.

- Volodya