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