Re: -var-list --locals proposal

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

Nick Roberts wrote:

>  > > which get
>  > > deleted when leaving the frame, and ordinary varobjs (which I guess
>  > > could get deleted
>  > > if they aren't globals).
>  > 
>  > I don't think gdb should be deleting any varobjs automatically. It's
>  > easier to program things if all varobj deletion is done by the
>  > frontend.
> 
> Well the variable doesn't exist anymore, and you're going to start
> accumulating
> varobjs.  

I don't think so. If there's a way in gdb to say "varobj really gone 
out of scope", and the frontend does not delete varobj infinitely
after getting such information, it's a bug in a frontend.

> It might be easier to recreate them when needed than keep track 
> of
> them.  However, if you implement something, maybe I'll change my mind.

Okay.

Note that this optimization is actually optional. The way I've specified
-var-list, it is not required to cache varobjs, it's allowed to.

>  > > Normally the user won't create two watch
>  > > expressions
>  > > for the same variable but I think that should be his business.  I
>  > > think it would be hard to avoid duplication as one watch expression
>  > > might be a child object.
>  > 
>  > Sorry, I don't quite understand. Can you clarify? I was always thinking
>  > that "watches" (same as gdb CLI "display") would be implemented by
>  > creating "selected frame" varobjs -- and those have nothing to do with
>  > -var-list.
> 
> I'm just saying that it probably doesn't matter if there is more than one
> variable object created for a single expression.  Maybe, though, that's
> because I'm not thinking of the varobjs for locals existing outside their
> frame.

Having two varobjs for a local is fine. The reason I don't want to
create varobjs when not necessary is that given that variable name
is not enough, varobj name is the only way for frontend to identify
a variable. If -var-list --locals returned varobj1 last time and
now report varobj2, the frontend should assume it's completely new
variable, delete UI item and create new. The old new item might
be expanded by user, deleting/creating kills that.

>  > >  > We'd need similar thing for function arguments, perhaps -- command
>  > >  > like
>  > >  > 
>  > >  > -var-list --arguments
>  > > 
>  > > In Insight arguments are listed alongside locals.  It might be a good
>  > > idea to have:
>  > > 
>  > >   -var-list --args-and-locals
>  > > 
>  > > and perhaps a field to say which is which.  It seems sensible to list
>  > > them all in one window.
>  > 
>  > Locals are also shown in the stack window.
> 
> I've never seen them there in any debugger that I've used.

Doh, I meant: 

        Arguments are also shown in the stack window.

- Volodya