This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: -var-update and address changes
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