-var-list --locals proposal

-var-list --locals proposal

[Vladimir Prus]

As promised, I have a proposal how to improve local variables
display in MI. At the moment, varobjs for locals should be created
by frontend, presumably after getting the list of local via -stack-list-locals.

That's good, but the list of locals generally change when stepping though
the program:

1. When entering or leaving a function, the list of locals changes
completely.

2. When entering a nested scope, new locals appear. A variable in a 
nested scope may have the same name as a variable in an inner scope.

3. When leaving a nested scope, some locals disappears.

At the moment, to reliably show all locals, the frontend is forced to emit
-stack-list-locals on each step. To handle the case where a new variable
is in nested scope and has the same name as a variable in outer scope,
the frontend should compute addresses of all variables on each step,
and notice when they change. This is rather nasty.

I propose to introduce a new command:

	-var-list --locals <frame>

This command returns variable objects corresponding to every local
variable that is "live" at the current position in the program. If at all
possible, the command tries to return previously returned variable object.

So, on each step, the frontend emits -var-list --locals and:

	1. For all variable objects it never seen, create new GUI
	elements.
	2. For all variable objects that were reported previously,
	but are no longer reported, delete GUI elements.

The 'frame' parameter specifies whose frame's locals should be
returned. I envision that varobjs be reused across frames. So,
if you invoke:

	-var-list --locals 1
	-exec-finish
	-var-list --locals 0

the second -var-list will try to return the same varobjs that were
returned by the first -var-list.

The question is what exactly can be considered "live" variables by
-var-list. I think that to avoid creating and destroying variable
objects as we step though inner blocks, -var-list should construct
varobjs for all variables in all blocks of a function.

Then, at each point in the function each varobj can be in one
of three states:

	1. Accessible in the current scope.
	2. Accessible in some of the outer scopes (hidden
	variable).
	3. Not accessible (variable in a scope we've not
	entered).

Transition between those states can be reported via -var-update. The
differences between (1) and (3) is already reported via "in_scope" attribute.
I'm not sure if we need to expose the difference between (2) and (3),
and if so, if it's better to introduce another attribute -- "hidden" with
values "true" and "false", or new attribute "visibility", with values of:

	"yes"
	"hidden"
	"out_of_scope"

In any way, this is rather small detail that can be changed later.

Comments?

- Volodya

Re: -var-list --locals proposal

[Eli Zaretskii]

> From: Vladimir Prus <ghost@cs.msu.su>
> Date: Fri, 5 Jan 2007 23:03:59 +0300
> 
> I propose to introduce a new command:
> 
> 	-var-list --locals <frame>

As you explain further, this will actually list all variables that are
visible in the current scope.  So a better name for this command would
be something like "-var-list --scope FRAME" or "-var-list --frame FRAME".

> I think that to avoid creating and destroying variable
> objects as we step though inner blocks, -var-list should construct
> varobjs for all variables in all blocks of a function.

Won't lazy creation (on as needed basis) be a better strategy?

Re: -var-list --locals proposal

[Vladimir Prus]

On Saturday 06 January 2007 13:39, Eli Zaretskii wrote:
> > From: Vladimir Prus <ghost@cs.msu.su>
> > Date: Fri, 5 Jan 2007 23:03:59 +0300
> > 
> > I propose to introduce a new command:
> > 
> > 	-var-list --locals <frame>
> 
> As you explain further, this will actually list all variables that are
> visible in the current scope.  So a better name for this command would
> be something like "-var-list --scope FRAME" or "-var-list --frame FRAME".

At the moment, the "KIND" option to -var-list is document as the kind of
objects for which varobjs are creates. Say

	-var-list --registers ...

creates varobjs for registers and

	-var-list --locals

will create varobjs for locals. On the contrary,

	-var-list --frame

would be somewhat inconsistent -- it does not create varobjs for frames.

> > I think that to avoid creating and destroying variable
> > objects as we step though inner blocks, -var-list should construct
> > varobjs for all variables in all blocks of a function.
> 
> Won't lazy creation (on as needed basis) be a better strategy?

It might be more efficient. However, different frontend have different ideas
how to show local vars. I believe that XCode, for example, shows all
locals as soon as you enter the function. Lazy creation would prevent such
usage.

- Volodya

Re: -var-list --locals proposal

[Eli Zaretskii]

> From: Vladimir Prus <ghost@cs.msu.su>
> Date: Sat, 6 Jan 2007 14:12:54 +0300
> Cc: gdb@sources.redhat.com
> > 
> > As you explain further, this will actually list all variables that are
> > visible in the current scope.  So a better name for this command would
> > be something like "-var-list --scope FRAME" or "-var-list --frame FRAME".
> 
> At the moment, the "KIND" option to -var-list is document as the kind of
> objects for which varobjs are creates. Say
> 
> 	-var-list --registers ...
> 
> creates varobjs for registers and
> 
> 	-var-list --locals
> 
> will create varobjs for locals. On the contrary,
> 
> 	-var-list --frame
> 
> would be somewhat inconsistent -- it does not create varobjs for frames.

Then perhaps we shouldn't reuse -var-list for this, but instead create
a new command entirely.

> > > I think that to avoid creating and destroying variable
> > > objects as we step though inner blocks, -var-list should construct
> > > varobjs for all variables in all blocks of a function.
> > 
> > Won't lazy creation (on as needed basis) be a better strategy?
> 
> It might be more efficient. However, different frontend have different ideas
> how to show local vars. I believe that XCode, for example, shows all
> locals as soon as you enter the function. Lazy creation would prevent such
> usage.

We shouldn't punish all front-ends because of what one of them does.
We could cater to XCode by providing a switch to do what it wants.

Re: -var-list --locals proposal

[Vladimir Prus]

On Saturday 06 January 2007 14:24, Eli Zaretskii wrote:
> > From: Vladimir Prus <ghost@cs.msu.su>
> > Date: Sat, 6 Jan 2007 14:12:54 +0300
> > Cc: gdb@sources.redhat.com
> > > 
> > > As you explain further, this will actually list all variables that are
> > > visible in the current scope.  So a better name for this command would
> > > be something like "-var-list --scope FRAME" or "-var-list --frame FRAME".
> > 
> > At the moment, the "KIND" option to -var-list is document as the kind of
> > objects for which varobjs are creates. Say
> > 
> > 	-var-list --registers ...
> > 
> > creates varobjs for registers and
> > 
> > 	-var-list --locals
> > 
> > will create varobjs for locals. On the contrary,
> > 
> > 	-var-list --frame
> > 
> > would be somewhat inconsistent -- it does not create varobjs for frames.
> 
> Then perhaps we shouldn't reuse -var-list for this, but instead create
> a new command entirely.

Or use:

	-var-list --all-locals-in-frame

? I don't want to introduce too many commands similar commands.

> > > > I think that to avoid creating and destroying variable
> > > > objects as we step though inner blocks, -var-list should construct
> > > > varobjs for all variables in all blocks of a function.
> > > 
> > > Won't lazy creation (on as needed basis) be a better strategy?
> > 
> > It might be more efficient. However, different frontend have different ideas
> > how to show local vars. I believe that XCode, for example, shows all
> > locals as soon as you enter the function. Lazy creation would prevent such
> > usage.
> 
> We shouldn't punish all front-ends because of what one of them does.

At this point, it's not clear if:

	1. Any frontend would need any other behaviour.
	2. What the performance overhead would be.

> We could cater to XCode by providing a switch to do what it wants.

I don't think we should introduce switches until a need for such switch
is demonstrated by a frontend that uses the current gdb version
and has some issue with that.

- Volodya

Re: -var-list --locals proposal

[Nick Roberts]

 > > > will create varobjs for locals. On the contrary,
 > > > 
 > > > 	-var-list --frame
 > > > 
 > > > would be somewhat inconsistent -- it does not create varobjs for frames.
 > > 
 > > Then perhaps we shouldn't reuse -var-list for this, but instead create
 > > a new command entirely.
 > 
 > Or use:
 > 
 > 	-var-list --all-locals-in-frame
 > 
 > ? I don't want to introduce too many commands similar commands.

Perhaps we could use Apple's "-stack-list-locals --create-varobjs" which would
minimise divergence, and "-var-list-registers" which is analogous to
"-var-list-children".  Also maybe "-var-list --locals" would share more code
with the existing -stack-list-locals than with the proposed
"-var-list --registers".

 > > > > > I think that to avoid creating and destroying variable
 > > > > > objects as we step though inner blocks, -var-list should construct
 > > > > > varobjs for all variables in all blocks of a function.
 > > > > 
 > > > > Won't lazy creation (on as needed basis) be a better strategy?
 > > > 
 > > > It might be more efficient. However, different frontend have different
 > > > ideas how to show local vars. I believe that XCode, for example, shows
 > > > all locals as soon as you enter the function. Lazy creation would
 > > > prevent such usage.

I've not seen XCode but Insight only shows the variables that are in scope
are displayed initially and others appear as they come into scope.  Then
as variables go out of scope they are greyed out.

 > > We shouldn't punish all front-ends because of what one of them does.
 > 
 > At this point, it's not clear if:
 > 
 > 	1. Any frontend would need any other behaviour.
 > 	2. What the performance overhead would be.


All GDB has to do is:

a) Report whether the variable is in scope when the variable object is
   created.

b) Report when it comes into/goes out of scope (as already done).

And the frontend developer can choose the behaviour.

 > > We could cater to XCode by providing a switch to do what it wants.

Apple have their own version of GDB so there is no need for a switch.

 > I don't think we should introduce switches until a need for such switch
 > is demonstrated by a frontend that uses the current gdb version
 > and has some issue with that.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: -var-list --locals proposal

[Vladimir Prus]

Nick Roberts wrote:

>  > > > will create varobjs for locals. On the contrary,
>  > > > 
>  > > > -var-list --frame
>  > > > 
>  > > > would be somewhat inconsistent -- it does not create varobjs for
>  > > > frames.
>  > > 
>  > > Then perhaps we shouldn't reuse -var-list for this, but instead
>  > > create a new command entirely.
>  > 
>  > Or use:
>  > 
>  > -var-list --all-locals-in-frame
>  > 
>  > ? I don't want to introduce too many commands similar commands.
> 
> Perhaps we could use Apple's "-stack-list-locals --create-varobjs" which
> would minimise divergence, and "-var-list-registers" which is analogous to
> "-var-list-children".  Also maybe "-var-list --locals" would share more
> code with the existing -stack-list-locals than with the proposed
> "-var-list --registers".

Perhaps that's something we should discuss last.

>  > > > > > I think that to avoid creating and destroying variable
>  > > > > > objects as we step though inner blocks, -var-list should
>  > > > > > construct varobjs for all variables in all blocks of a
>  > > > > > function.
>  > > > > 
>  > > > > Won't lazy creation (on as needed basis) be a better strategy?
>  > > > 
>  > > > It might be more efficient. However, different frontend have
>  > > > different ideas how to show local vars. I believe that XCode, for
>  > > > example, shows all locals as soon as you enter the function. Lazy
>  > > > creation would prevent such usage.
> 
> I've not seen XCode but Insight only shows the variables that are in scope
> are displayed initially and others appear as they come into scope.  Then
> as variables go out of scope they are greyed out.

I suppose this behaviour, if you consider it useful for your frontend,
can be done by not creating any UI representation for a varobj until
it comes into scope.

>  > > We shouldn't punish all front-ends because of what one of them does.
>  > 
>  > At this point, it's not clear if:
>  > 
>  > 1. Any frontend would need any other behaviour.
>  > 2. What the performance overhead would be.
> 
> 
> All GDB has to do is:
> 
> a) Report whether the variable is in scope when the variable object is
>    created.
> 
> b) Report when it comes into/goes out of scope (as already done).
> 
> And the frontend developer can choose the behaviour.

So,

        -var-list --all-locals

should create varobj for all locals in a function, and indicate which
are in scope at the moment of creation? I think that's good.

- Volodya

Re: -var-list --locals proposal

[Daniel Jacobowitz]

On Fri, Jan 05, 2007 at 11:03:59PM +0300, Vladimir Prus wrote:
> At the moment, to reliably show all locals, the frontend is forced to emit
> -stack-list-locals on each step. To handle the case where a new variable
> is in nested scope and has the same name as a variable in outer scope,
> the frontend should compute addresses of all variables on each step,
> and notice when they change. This is rather nasty.
> 
> I propose to introduce a new command:
> 
> 	-var-list --locals <frame>
> 
> This command returns variable objects corresponding to every local
> variable that is "live" at the current position in the program. If at all
> possible, the command tries to return previously returned variable object.
> 
> So, on each step, the frontend emits -var-list --locals and:
> 
> 	1. For all variable objects it never seen, create new GUI
> 	elements.
> 	2. For all variable objects that were reported previously,
> 	but are no longer reported, delete GUI elements.

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".

> The question is what exactly can be considered "live" variables by
> -var-list. I think that to avoid creating and destroying variable
> objects as we step though inner blocks, -var-list should construct
> varobjs for all variables in all blocks of a function.

We could call this --all-locals; I think that "for the given frame"
is implied.

> Transition between those states can be reported via -var-update. The
> differences between (1) and (3) is already reported via "in_scope" attribute.
> I'm not sure if we need to expose the difference between (2) and (3),
> and if so, if it's better to introduce another attribute -- "hidden" with
> values "true" and "false", or new attribute "visibility", with values of:
> 
> 	"yes"
> 	"hidden"
> 	"out_of_scope"

C and C++ both call this "hidden"; GCC calls it shadowing (-Wshadow).
You're right that this is just a detail.  I'll try not to make my
frequent mistake of focusing too much on the hardest and least useful
case :-)

-- 
Daniel Jacobowitz
CodeSourcery

Re: -var-list --locals proposal

[Vladimir Prus]

Daniel Jacobowitz wrote:

> On Fri, Jan 05, 2007 at 11:03:59PM +0300, Vladimir Prus wrote:
>> At the moment, to reliably show all locals, the frontend is forced to
>> emit -stack-list-locals on each step. To handle the case where a new
>> variable is in nested scope and has the same name as a variable in outer
>> scope, the frontend should compute addresses of all variables on each
>> step, and notice when they change. This is rather nasty.
>> 
>> I propose to introduce a new command:
>> 
>> -var-list --locals <frame>
>> 
>> This command returns variable objects corresponding to every local
>> variable that is "live" at the current position in the program. If at all
>> possible, the command tries to return previously returned variable
>> object.
>> 
>> So, on each step, the frontend emits -var-list --locals and:
>> 
>> 1. For all variable objects it never seen, create new GUI
>> elements.
>> 2. For all variable objects that were reported previously,
>> but are no longer reported, delete GUI elements.
> 
> 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.



>> The question is what exactly can be considered "live" variables by
>> -var-list. I think that to avoid creating and destroying variable
>> objects as we step though inner blocks, -var-list should construct
>> varobjs for all variables in all blocks of a function.
> 
> We could call this --all-locals; I think that "for the given frame"
> is implied.

--all-locals is fine with me.

>> Transition between those states can be reported via -var-update. The
>> differences between (1) and (3) is already reported via "in_scope"
>> attribute. I'm not sure if we need to expose the difference between (2)
>> and (3), and if so, if it's better to introduce another attribute --
>> "hidden" with values "true" and "false", or new attribute "visibility",
>> with values of:
>> 
>> "yes"
>> "hidden"
>> "out_of_scope"
> 
> C and C++ both call this "hidden"; GCC calls it shadowing (-Wshadow).
> You're right that this is just a detail.  I'll try not to make my
> frequent mistake of focusing too much on the hardest and least useful
> case :-)

:-)

- Volodya

Re: -var-list --locals proposal

[Daniel Jacobowitz]

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.

I think I saw something about frame events on gdb-patches but I'm not
going to try to catch up on that list until the weekend, I think.

-- 
Daniel Jacobowitz
CodeSourcery

Re: -var-list --locals proposal

[Vladimir Prus]

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


 

Re: -var-list --locals proposal

[Nick Roberts]

 > 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.

I think there should varobjs that are created from locals which get deleted
when leaving the frame, and ordinary varobjs (which I guess could get deleted
if they aren't globals).  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.

 > 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.

 > 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.



-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: -var-list --locals proposal

[Vladimir Prus]

Nick Roberts wrote:

>  > 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.
> 
> I think there should varobjs that are created from locals 

The above sentence looks grammatically incorrect.

> 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.

> 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.

>  > 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. 

- Volodya

Re: -var-list --locals proposal

[Nick Roberts]

 > >  > 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.
 > > 
 > > I think there should varobjs that are created from locals 
 > 
 > The above sentence looks grammatically incorrect.

That's because it's not a sentence but part of one i.e a phrase, but I don't
want to get smart because my Russian is non-existant.  It's probably lazy
English.  I'm trying to say that while you appear to be talking about keeping
track of varobjs across frames, for locals, I'm thinking of only keeping them
for the current frame.

 > > 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.  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.

 > > 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.

 > >  > 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.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: -var-list --locals proposal

[Vladimir Prus]

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