This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gcc HEAD dwarf-2, synthetic methods no longer public, gdb confused


On Sun, Jul 04, 2004 at 07:19:19AM -0400, Michael Chastain wrote:
> Here's my next problem with gcc HEAD -gdwarf-2.  I suspect this is a bug
> in gdb rather than gcc.
> 
> I've got a test program with a class, Alpha, that has a
> compiler-synthesized assignment operator.  That is, Alpha does not
> declare or define an operator=, so the C++ compiler has to generate
> one itself.
> 
> With the old gcc HEAD, the dwarf-2 info looks like this:
> 
>  <2><f6b>: Abbrev Number: 21 (DW_TAG_subprogram)
>      DW_AT_sibling     : <f98>
>      DW_AT_external    : 1
>      DW_AT_name        : (indirect string, offset: 0x9a3): operator=
>      DW_AT_MIPS_linkage_name: _ZN5AlphaaSERKS_
>      DW_AT_type        : <fd1>
>      DW_AT_artificial  : 1
>      DW_AT_declaration : 1
> 
> With the new gcc HEAD, the dwarf-2 info looks like this:
> 
>  <2><f6b>: Abbrev Number: 21 (DW_TAG_subprogram)
>      DW_AT_sibling     : <f86>
>      DW_AT_name        : (indirect string, offset: 0x999): operator=
>      DW_AT_type        : <fbd>
>      DW_AT_artificial  : 1
>      DW_AT_declaration : 1
> 
> The difference is that DW_AT_external and DW_AT_MIPS_linkage_name
> have gone away.

Is the method code emitted beforehand?  How about afterwards?  I'm
assuming that it is emitted in both cases.  Is it marked .globl before
and after?

> I narrowed this down to this one large patch:
> 
>   2004-06-21  Mark Mitchell  <mark@codesourcery.com>
> 
> 	...
>         * method.c (use_thunk): Use start_preparsed_function.
>         (synthesize_method): Likewise.
>         (implicitly_declare_fn): Build FUNCTION_DECLs, not declarators.
> 	...
> 
> The difference is in implicitly_declare_fn.  The old gcc HEAD
> built a tree node with TREE_PUBLIC set, and the new gcc HEAD
> does not.  This might be an accidental change in the middle of
> the big declarator change.

This we'd have to ask Mark about :)  CC'd.

> When gdb sees the new debug info with no DW_AT_external and no
> DW_AT_MIPS_linkage_name, it gets a little strange with the type
> information.
> 
>   # gdb HEAD 2004-06-29
>   # gcc HEAD 2004-06-22 07:10:00 UTC
>   (gdb) ptype Alpha
>   type = class Alpha {
>     private:
>       int a_;
>       Empty empty_;
> 
>     public:
>       Alpha(void);
>   }
> 
>   # gdb HEAD 2004-06-29
>   # gcc HEAD 2004-06-22 07:20:00 UTC
>   (gdb) ptype Alpha
>   type = void (Alpha * const, const Alpha &)
> 
> Interestingly, this does not affect stabs+.  It does affect dwarf-2.
> Also, 'ptype class Alpha' works; it's only 'ptype Alpha' that is broken.

This is a longstanding bug; it just seems to happen sometimes. Probably
the order we parse something has changed.  DW_AT_MIPS_linkage_name
should die anyway, but GDB currently still requires it.

> ... is this good dwarf-2 info?

Maybe.  The change in DW_AT_external, at least, is probably bad.  

>   ... if so, can we fix the dwarf-2 reader to handle it?

Probably not easily.  It depends what caused the class/function bug.

>   ... if not, i will file a gcc pr

-- 
Daniel Jacobowitz


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]