The use of anonymous structure does seem to be the problem. I also missed the
fact that the TYPE_DEF DIE is missing from the DWARF data. If the TYPE
_DEF DIE was in the DWARF data, I could still parse the anonymous type.
Do you think the TYPE_DEF DIE should be part of the output? Is this a GNU
bug or just an unsupported feature?
Thanks.
--- On Fri, 1/22/10, Michael Eager <ea...@eagercon.com> wrote:
> From: Michael Eager <ea...@eagercon.com>
> Subject: Re: Mangled Typedef names in GNU 4.1.2 DWARF data?
> To: "Ron Louzon" <louz...@yahoo.com>
> Cc: gcc@gcc.gnu.org
> Date: Friday, January 22, 2010, 4:39 PM
> Ron Louzon wrote:
> > The GNU 4.1.2 C++ compiler is mangling typedef names
> to the point that they are not retrievable from the DWARF
> data.
> >
> > For example, the type BASE_UNION is defined as
> >
> > typedef union
> > {
> > char ch;
> > int iVal;
> > long IVal;
> > } BASE_UNION;
>
> This is an anonymous union which is typedef'ed to
> BASE_UNION.
>
> >
> > The GNU 4.1.2 compiler generates the following DWARF
> data for this type
> >
> > <1><1279>: Abbrev Number: 35
> (DW_TAG_union_type)
> > <127a>
> DW_AT_sibling :
> <12a8>
> > <127e>
> DW_AT_name :
> $_4
> > <1282>
> DW_AT_byte_size :
> 4
> > <1283>
> DW_AT_decl_file :
> 35
> > <1284>
> DW_AT_decl_line :
> 29
>
> This doesn't look correct. The union has no name, so
> DW_AT_name should
> not be present or should be null. From the DWARF v.3
> spec:
>
> 2.15 Identifier Names
>
> Any debugging information entry representing a
> program entity that has been
> given a name may have a DW_AT_name attribute, whose
> value is a string
> representing the name as it appears in the source
> program. A debugging
> information entry containing no name attribute, or
> containing a name attribute
> whose value consists of a name containing a single
> null byte, represents a
> program entity for which no name was given in the
> source.
>
> > <2><1285>: Abbrev Number: 36
> (DW_TAG_member)
> > <1286>
> DW_AT_name :
> ch
> > <1289>
> DW_AT_decl_file :
> 35
> > <128a>
> DW_AT_decl_line :
> 30
> > <128b>
> DW_AT_type :
> <c0d>
> > <2><128f>: Abbrev Number: 36
> (DW_TAG_member)
> > <1290>
> DW_AT_name :
> iVal
> > <1295>
> DW_AT_decl_file :
> 35
> > <1296>
> DW_AT_decl_line :
> 31
> > <1297>
> DW_AT_type :
> <b7f>
> > <2><129b>: Abbrev Number: 36
> (DW_TAG_member)
> > <129c>
> DW_AT_name :
> IVal
> > <12a1>
> DW_AT_decl_file :
> 35
> > <12a2>
> DW_AT_decl_line :
> 32
> > <12a3>
> DW_AT_type :
> <b86>
> >
> > Notice that the union name has been changed to "$_4"
> in DIE <1279>.
> >
> > The GNU 3.4.4 compiler generates the following DWARF
> data from the same source code:
> >
> > <1><11d0>: Abbrev Number: 27
> (DW_TAG_union_type)
> > DW_AT_sibling
> : <123f>
> > DW_AT_name
> : (indirect string, offset: 0x6e):
> BASE_UNION
> > DW_AT_byte_size :
> 4
> > DW_AT_decl_file :
> 3
> > DW_AT_decl_line :
> 29
>
> This is similarly incorrect. The union has no name.
>
>
> > Why is GNU 4.1.2 generating the mangled type name and
> how do I correct this to generate the real type name?
>
> A better question might by why there is no DW_TAG_typedef
> DIE which looks like
>
> DW_TAG_typedef
>
> DW_AT_name: BASE_UNION
>
> DW_AT_type: <1279>
>
> BTW gcc-4.3.2 generates
>
> DW_AT_name: <anonymous union>
>
> which is also incorrect.
>
>
>
> -- Michael eager ea...@eagercon.com
> 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
>
