PR debug/47510

Hello,

consider the example below:

    class C {
    public:
      C() {}
      ~C() {}
    };
    typedef struct {
      C m;
    } t;
    typedef t s;
    s v;

The bug is that the DW_TAG_typedef of the naming typedef t has
children DIEs that describe the constructor and destructor of the
anonymous struct named by t.

This is a leftover of PR debug/46101.

In this case when callgraph asks the dwarf backend to emit debug info
for the constructor of the anonymous struct, get_context_die [called
with the anonymous struct's tree] returns the DIE of the naming
typedef. The dwarf emitter then hangs the DIE of the constructor off
the typedef.

This patch strips the naming typedef from the result of
get_context_die.


Tested on x86_64-unknown-linux-gnu against trunk.

>>>>> "Dodji" == Dodji Seketeli <dodji@redhat.com> writes:

Dodji>     class C {
Dodji>     public:
Dodji>       C() {}
Dodji>       ~C() {}
Dodji>     };
Dodji>     typedef struct {
Dodji>       C m;
Dodji>     } t;
Dodji>     typedef t s;
Dodji>     s v;

Before this patch, we got the weird result of a DW_TAG_typedef with
children.  This was weird because DWARF doesn't mention this as a
possibility, so no DWARF readers are prepared to do anything sensible
with it.

After this patch, we get a different, and IMO worse, weird result:

 <1><70>: Abbrev Number: 8 (DW_TAG_structure_type)
    <71>   DW_AT_byte_size   : 1	
    <72>   DW_AT_decl_file   : 1	
    <73>   DW_AT_decl_line   : 7	
    <74>   DW_AT_sibling     : <0xb0>	
[...]
 <2><84>: Abbrev Number: 10 (DW_TAG_subprogram)
    <85>   DW_AT_name        : t	
    <87>   DW_AT_artificial  : 1	
    <88>   DW_AT_declaration : 1	
    <89>   DW_AT_object_pointer: <0x91>	
    <8d>   DW_AT_sibling     : <0x98>	
[...]
 <1><b0>: Abbrev Number: 12 (DW_TAG_typedef)
    <b1>   DW_AT_name        : t	
    <b3>   DW_AT_decl_file   : 1	
    <b4>   DW_AT_decl_line   : 9	
    <b5>   DW_AT_type        : <0x70>	


That is, the typedef DIE is a normal typedef -- good so far.  But, it is
a typedef of an anonymous struct that has the struct's members.  This
would be ok, except one of the members is the (synthetic) constructor
't'.

In order to handle this, I think gdb is going to have to look for
typedefs to anonymous structs, then search the struct for a constructor
(or maybe destructor is more reliable) matching the typedef name.  That
is because there is no marker indicating "this anonymous struct was
given a canonical name via a C++ typedef".

It seems to me that it would be simpler to just emit 't' as an ordinary
DW_TAG_structure_type and not emit a typedef at all.  This is perhaps
mildly different from what the sources say, but it is a very obscure
case.  Jan did think of one case where it matters: if you want to be
able to find the location of the typedef separately from the location of
the struct definition.  However, I think this is not very important, and
certainly less important than the gyrations debuginfo readers have to go
through to reconstruct 't'.

Tom

>>>>> "Tom" == Tom Tromey <tromey@redhat.com> writes:

Tom> It seems to me that it would be simpler to just emit 't' as an ordinary
Tom> DW_TAG_structure_type and not emit a typedef at all.

After a lot of discussion on irc, we came up with another idea: extend
this patch to add DW_AT_linkage_name == 't' to the anonymous structure.
This makes the DWARF remain a faithful representation of the C++, but
also makes it simple for debuginfo readers to understand what is going
on.  In particular I think it will make the gdb side of this tractable.

Tom