Re: -var-update and address changes

[Jim Ingham <jingham at apple dot 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