Re: -var-list --locals proposal

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

On Tuesday 16 January 2007 10:18, Daniel Jacobowitz wrote:
> On Tue, Jan 16, 2007 at 10:00:44AM +0300, Vladimir Prus wrote:
> > > I think most of the complexity in this will come from reusing varobjs.
> > > Couldn't we do this with -var-update?  The meaning of in_scope="false"
> > > is a bit unclear today, since we use it for anything whose value we
> > > can't find, and in optimized code a variable can go in and out of
> > > scope.  So using that might not be a good idea.  We could add another
> > > marker, though, such as frame_exited="true" to indicate that a varobj's
> > > associated frame has returned (or otherwise disappeared from the
> > > stack).  A varobj would never transition from frame_exited="true" to
> > > frame_exited="false".
> > 
> > I think it would be good to reuse varobj accross the frames. So,
> > if you're in some function and look at its locals and then enter
> > another function and try to look at parents variables you get
> > the same varobjs. I don't think that creation of varobj is 
> > so expensive in gdb itself -- but for frontend it's more
> > convenient to always have the same varobj associated with 
> > a variable.
> 
> But, if we can export frame IDs in some safe and useful way to the
> frontend, we can avoid having to recreate them at all.  The front
> end would just know that they were the same, and not reissue -var-list.

So, you either have frame_id->list_of_varobjs mapping in gdb, or in
the frontend. I'm not sure which one is better. If this kept in a frontend,
you'd also need notification "frame id XXX has died" so that
the frontend can clean up its mapping.

We'd need similar thing for function arguments, perhaps -- command like

	-var-list --arguments

that would try hard to reuse varobjs and which command can be used
to implement stack display. I'd much prefer to have this logic in gdb,
because doing it in the frontend is not anyway simpler, I think.

- Volodya