Re: -var-list --locals proposal

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

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