This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: -var-list --locals proposal
> 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.