Re: -var-update and address changes

[Jim Ingham <jingham@apple.com>]

On Apr 12, 2006, at 5:04 AM, Vladimir Prus wrote:

>
> Hi,
> I'm running into what looks like a bug in -var-update. Basically, I  
> create a
> varobj with "&variable", then I enter a function that has a  
> variable with
> the same name, and -var-update does not report anything.
>
> Here's the code, and the gdb session.
>
>     int foo()
>     {
>         int i = 10;
>         ++i;
>         return i;
>     }
>
>     int main()
>     {
>         int i = 10;
>         i = foo();
>         return i;
>     }
>
> And here's the session
>
>     -break-insert a.cpp:12
>     ^done,....
>     (gdb)
>     -break-insert a.cpp:5
>     ^done,....
>     (gdb)
>     -exec-run
>     ^running
>     (gdb)
>     *stopped,reason="breakpoint-hit",.....
>     (gdb)
>     -var-create TEST * &i
>     ^done,name="TEST",numchild="1",type="int *"
>     (gdb)
>     -exec-continue
>     ^running
>     (gdb)
>     *stopped,reason="breakpoint-hit",.......
>     (gdb)
>     -var-update *
>     ^done,changelist=[]
>     (gdb)
>
> The value of "&i" changes, but -var-update does not report this.  
> This can be
> explained by the fact that varobjs are "bound" to the stack frame  
> where
> they were created, but that "binding" is not mentioned in  
> documentation.
>
> The problem I'm trying to solve is this:
> 1. In some frame, I create varobj for 'i'.
> 2. After continue, I see that there's local variable 'i', and I  
> want to find
> out if previously-created varobj can be used to show this local  
> 'i', or if
> I should create new 'i'.
>
>    - I can't use frame ids because gdb only prints code address,  
> and two
>      different stack frames can have the same code address.
>    - I can't use -var-update, because it does not seem to report  
> anything
>    - I can't use -var-update on variable addresses, because of the  
> above
>      report
>
> 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.

>
> 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.  We also tell what the valid block is, but  
Xcode doesn't use this info at present.

This all works in our branch if you want to see one example of how to  
do it.

Jim