Re: -var-list --locals proposal

[Vladimir Prus <ghost@cs.msu.su>]

Nick Roberts wrote:

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

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

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

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

- Volodya