Re: -var-list --locals proposal

[Nick Roberts <nickrob@snap.net.nz>]

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