Re: -var-list --locals proposal

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

 > >  > So, you either have frame_id->list_of_varobjs mapping in gdb, or in
 > >  > the frontend. I'm not sure which one is better. If this kept in a
 > >  > frontend, you'd also need notification "frame id XXX has died" so that
 > >  > the frontend can clean up its mapping.
 > > 
 > > I think there should varobjs that are created from locals 
 > 
 > The above sentence looks grammatically incorrect.

That's because it's not a sentence but part of one i.e a phrase, but I don't
want to get smart because my Russian is non-existant.  It's probably lazy
English.  I'm trying to say that while you appear to be talking about keeping
track of varobjs across frames, for locals, I'm thinking of only keeping them
for the current frame.

 > > which get 
 > > deleted when leaving the frame, and ordinary varobjs (which I guess could
 > > get deleted
 > > if they aren't globals).  
 > 
 > I don't think gdb should be deleting any varobjs automatically. It's
 > easier to program things if all varobj deletion is done by the frontend.

Well the variable doesn't exist anymore, and you're going to start accumulating
varobjs.  It might be easier to recreate them when needed than keep track of
them.  However, if you implement something, maybe I'll change my mind.

 > > Normally the user won't create two watch 
 > > expressions
 > > for the same variable but I think that should be his business.  I think it
 > > would be hard to avoid duplication as one watch expression might be a
 > > child object.
 > 
 > Sorry, I don't quite understand. Can you clarify? I was always thinking that
 > "watches" (same as gdb CLI "display") would be implemented by creating
 > "selected frame" varobjs -- and those have nothing to do with -var-list.

I'm just saying that it probably doesn't matter if there is more than one
variable object created for a single expression.  Maybe, though, that's because
I'm not thinking of the varobjs for locals existing outside their frame.

 > >  > We'd need similar thing for function arguments, perhaps -- command like
 > >  > 
 > >  > -var-list --arguments
 > > 
 > > In Insight arguments are listed alongside locals.  It might be a good idea
 > > to have:
 > > 
 > >   -var-list --args-and-locals
 > > 
 > > and perhaps a field to say which is which.  It seems sensible to list them
 > > all in one window.
 > 
 > Locals are also shown in the stack window. 

I've never seen them there in any debugger that I've used.

-- 
Nick                                           http://www.inet.net.nz/~nickrob