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