Re: [RFC] Dont skip DW_TAG_member in load_partial_dies()

[Manoj Iyer <manjo@austin.ibm.com>]

Elena,

Any comments on this patch of mine? ok to commit?


Thanks
-----
manjo
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ Cogito ergo sum                                                          +
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

On Tue, 15 Feb 2005, Daniel Jacobowitz wrote:

> On Tue, Feb 15, 2005 at 03:06:57PM -0600, Manoj Iyer wrote:
> >
> > GDB prints internal error with C++ application produced by XLC.
>
> Many of the tests in the GDB testsuite already will probably produce
> this error, if you want to try running the testsuite with xlC.  It
> probably won't be easy, though.
>
> I'm copying this to Elena, since she is the maintainer of the DWARF-2
> reader.  Your patch looks right to me.  In fact, I've been working on
> running the GDB testsuite using ARM's compiler today, and I have a
> patch that looks exactly like this in my working directory :-)
>
> > When the above testcase is compiled -m64 by XLC, GDB generates an internal
> > error:
> >
> > "internal-error: could not find partial DIE in cache"
> >
> > GCC creates a DWARF TAG for "a" as DW_TAG_variable and XLC creates
> > DW_TAG_member. GDB throws away TAGS that it find as uninteresting. In this
> > case DW_TAG_member. (this is in dwarf2read.c function:
> > load_partial_dies(). )
> >
> > GCC created DWARF information
> > -------------------------------
> >  <2><102>: Abbrev Number: 13 (DW_TAG_variable)
> >      DW_AT_name        : a
> >      DW_AT_decl_file   : 1
> >      DW_AT_decl_line   : 13
> >      DW_AT_MIPS_linkage_name: _ZN1XIiE1aE
> >      DW_AT_type        : <d5>
> >      DW_AT_external    : 1
> >      DW_AT_declaration : 1
> >
> > XLC created DWARF information
> > ------------------------------
> >  <2><96>: Abbrev Number: 5 (DW_TAG_member)
> >      DW_AT_name        : a
> >      DW_AT_accessibility: 1     (public)
> >      DW_AT_declaration : 1
> >      DW_AT_type        : <78>
> >
> >
> > GCC in this case is producing wrong information. According to DWARF
> > spec:
> >
> > " If the variable entry represents the defining declaration for a C++
> > static data member of a structure, class or union, the entry has a
> > DW_AT_specification attribute, whose value is a reference to the debugging
> > information entry representing the declaration of this data member. The
> > referenced entry has the tag DW_TAG_member and will be a child of some
> > class, structure or union type entry. "
> >
> > So I think GDB needs to handle the DW_TAG_member and not skip it, when
> > dealing with  C++.
> >
> > Here is a patch to GDB that will fix this problem
> >
> > ================ Patch to gdb ==================
> > 2005-02-15  Manoj Iyer  <manjo@austin.ibm.com>
> >
> >         * dwarf2read.c (load_partial_dies): Save DIE with tag
> >         DW_TAG_member, generated by XLC when compiling C++ application.
> >
> > diff -Naur ./old/src/gdb/dwarf2read.c ./new/src/gdb/dwarf2read.c
> > --- ./old/src/gdb/dwarf2read.c  2005-02-15 11:13:05.000000000 -0600
> > +++ ./new/src/gdb/dwarf2read.c  2005-02-22 10:24:08.000000000 -0600
> > @@ -5167,7 +5167,8 @@
> >           && abbrev->tag != DW_TAG_enumerator
> >           && abbrev->tag != DW_TAG_subprogram
> >           && abbrev->tag != DW_TAG_variable
> > -         && abbrev->tag != DW_TAG_namespace)
> > +         && abbrev->tag != DW_TAG_namespace
> > +         && abbrev->tag != DW_TAG_member)
> >         {
> >           /* Otherwise we skip to the next sibling, if any.  */
> >           info_ptr = skip_one_die (info_ptr + bytes_read, abbrev, cu);
> >
> > ========================= END PATCH ======================
> >
> >
> > ok to commit?
> >
> > Thanks
> > -----
> > manjo
> > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > + Cogito ergo sum                                                          +
> > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >
>
> --
> Daniel Jacobowitz
> CodeSourcery, LLC
>