Re: variable objects and registers

Vladimir Prus
2006-12-20T18:39:27Z

Nick Roberts wrote:

> > ? Or maybe we should not mix easy "create one varobj from expression"
> > command with "create a bunch of varobj" command and add the following:
> >
> > -var-create-and-list --registers ...
> > -var-create-and-list --locals ...
> > -var-create-and-list --whatever-else ...
>
> A separate command does indeed seem best.
>
> > or just "-var-list"? On the other hand, on Apple branch the varobjs for
> > locals are created using
> >
> > -stack-list-locals --make-varobjs
>
> Most of the functionality seems to come from varobj.c so, unless Apple
> contribute this code to the FSF repository, I see no need to follow their
> approach.

I don't think this particular interface decision is important, but I don't
follow your general principle. It does not matter if Apple ports their code
to FSF, or we do it -- if differences are introduces for no good reason,
it makes it harder to merge changes for everyone, and that's bad.

>
> > I slightly prefer
> >
> > -var-list --locals
>
> -var-list-create --locals? -var-create-list --locals?

I've settled on -var-list. I don't think 'create' clarifies much,
and this is not user command, and '-var-list-children' also creates
variable objects without having 'create' in the name.

>
> Insight creates variable objects for display of locals. The delay is
> quite apparent when there are more than a couple of them, but it only
> updates when
> the frame changes.

By "updates" you mean '-var-update' or regetting new list of locals and
creating new vars?

> In Emacs, I update after every GDB command using "info
> locals" which is quicker

Quicker than what? -var-update? Is this a measurable difference? If
so, we should fix it.

> but not as good. We need to find a way to detect
> when the frame changes

FWIW, KDevelop uses "info frame"

> and report it e.g
>
> * NOTIFY-ASYNC-OUTPUT contains supplementary information that the
> client should handle (e.g., a new breakpoint information). All
> notify output is prefixed by `='.
>
> =frame-changed
>
> I started looking at this in the thread
>
> http://sourceware.org/ml/gdb/2006-06/msg00162.html
>
> but didn't make good progress.

I think that we need more higher-level notification -- namely "new locals
appeared" and either:
- "varobj now refers to different object"
- or have a command that creates varobjs for all variables
in a function.

That way, we won't need to guess how varobjs should be changes when frame id
changes.

>
> > >...
> > > +static struct varobj *
> > > +create_varobj_in_frame (char *name, char *expression, char *frame)
> > > +{
> > > + CORE_ADDR frameaddr = 0;
> > > + struct cleanup *cleanup;
> > > + enum varobj_type var_type;
> > > +
> > > + if (strcmp (frame, "*") == 0)
> > > + var_type = USE_CURRENT_FRAME;
> > > + else if (strcmp (frame, "@") == 0)
> > > + var_type = USE_SELECTED_FRAME;
> > > + else
> > > + {
> > > + var_type = USE_SPECIFIED_FRAME;
> > > + frameaddr = string_to_core_addr (frame);
> > > + }
> > > +
> > > + if (varobjdebug)
> > > + fprintf_unfiltered (gdb_stdlog,
> > > + "Name=\"%s\", Frame=\"%s\" (0x%s),
> > > Expression=\"%s\"\n",
> > > + name, frame, paddr (frameaddr), expression);
> > > +
> > > + return varobj_create (name, expression, frameaddr, var_type);
> > > +}
> > > +
> > >
> > > I think the function above should go in varobj.c
> >
> > Then, the varobj.c would have to expose magic "@" and "*" values in its
> > interface. I think it's better to keep this closer to parsing code and
> > keep varobj.c separated.
>
> Yes. OK, in that case I would call the function create_var_in_frame.

That function creates and returns variable object. Calling
it 'create_var_in_frame' would imply that it creates some 'var',
and that would not be accurate.

> Likewise with existing functions:
>
> varobj_update_one --> var_update
> print_varobj --> print_var

This one, too, prints variable object.

> so that they are in the file you would expect to find them.

I'm not sure. I don't know why a name of a function should map to the
name of the file in the way you indicate.

- Volodya