This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: Variable objects: references formatting
- From: Vladimir Prus <ghost at cs dot msu dot su>
- To: Nick Roberts <nickrob at snap dot net dot nz>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Thu, 4 May 2006 09:30:10 +0400
- Subject: Re: Variable objects: references formatting
- References: <17497.14121.225320.477428@farnswood.snap.net.nz>
On Thursday 04 May 2006 03:05, Nick Roberts wrote:
> There are som many things about this patch that I don't understand:
> > Index: varobj.c
> > ===================================================================
> > RCS file: /cvs/src/src/gdb/varobj.c,v
> > retrieving revision 1.58
>
> Version 1.59 has been in the repository for over a month, so how come this
> patch is against 1.58?
I've at least 2 other changes to that file, and corresponding patches were
neither applied nor rejected, AFAICT. I'd rather not update the file yet.
> > diff -u -r1.58 varobj.c
> > @@ -2055,8 +2219,14 @@
>
> I'm not used to unified diffs, but as insertion appears to be done at the
> same place why is it not something like:
>
> @@ -2055,8 +2055,14 @@
I'm sorry, I don't understand that question. This hunk was cut from a larger
diff, maybe that explains something?
> > {
> > /* BOGUS: if val_print sees a struct/class, it will print out its
> > children instead of "{...}" */
> > + struct type* type = get_type (var);
> > + /* Strip top-level references. */
> > + while (TYPE_CODE (type) == TYPE_CODE_REF)
> > + {
> > + type = TYPE_TARGET_TYPE (type);
> > + }
> >
> > - switch (TYPE_CODE (get_type (var)))
> > + switch (TYPE_CODE (type))
> > {
> > case TYPE_CODE_STRUCT:
> > case TYPE_CODE_UNION:
>
> Most importantly, however, the preamble is about -data-evaluate-expression
> but AFAICS this doesn't call c_value_of_variable.
Sure it does. KDevelop uses -data-evaluate-expression to fetch values, and
with this patch the value of "reference to structure" is rendered as "...",
just like I'd want.
>
> I have tested the output of -data-evaluate-expression on pointers to
> typedeffed structures and found that with the latter I get a {}-enclosed
> list of members with gcc 3.2 and {...} with gcc 4.1. More generally, I
> have found that gcc 4.1 treats typedefs differently, which leads to errors
> with variable objects.
How *pointers* to typedeffed structures are relevant to this patch? Now, maybe
we need to call 'check_typedef' in one more place -- after stripping
reference, to make sure typedefs to structures are also rendered as "...".
Is that what you're saying? And what errors do you see with gcc 4.1?
- Volodya