This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: variable objects and registers
> ? 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