Re: -var-list --locals proposal

[Vladimir Prus <ghost at cs dot msu dot su>]

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