Re: variable objects and registers

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

 > ? 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 slightly prefer
 > 
 >         -var-list --locals

-var-list-create --locals?  -var-create-list --locals?

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.  In Emacs, I update after every GDB command using "info
locals" which is quicker but not as good.  We need to find a way to detect when
the frame changes 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.

 > >...
 > > +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.  Likewise
with existing functions:

varobj_update_one    -->  var_update
print_varobj         -->  print_var

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

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