Re: variable objects and registers

[Vladimir Prus <ghost at cs dot msu dot su>]

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