From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32183 invoked by alias); 4 Jul 2004 14:52:34 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 32165 invoked from network); 4 Jul 2004 14:52:32 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 4 Jul 2004 14:52:32 -0000 Received: from drow by nevyn.them.org with local (Exim 4.34 #1 (Debian)) id 1Bh8Lq-0000b0-Pv; Sun, 04 Jul 2004 10:52:18 -0400 Date: Sun, 04 Jul 2004 14:52:00 -0000 From: Daniel Jacobowitz To: Michael Elizabeth Chastain , Mark Mitchell Cc: gdb@sources.redhat.com Subject: Re: gcc HEAD dwarf-2, synthetic methods no longer public, gdb confused Message-ID: <20040704145218.GA2095@nevyn.them.org> Mail-Followup-To: Michael Elizabeth Chastain , Mark Mitchell , gdb@sources.redhat.com References: <20040704111919.73AEA4B104@berman.michael-chastain.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040704111919.73AEA4B104@berman.michael-chastain.com> User-Agent: Mutt/1.5.5.1+cvs20040105i X-SW-Source: 2004-07/txt/msg00024.txt.bz2 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>: Abbrev Number: 21 (DW_TAG_subprogram) > DW_AT_sibling : > DW_AT_external : 1 > DW_AT_name : (indirect string, offset: 0x9a3): operator= > DW_AT_MIPS_linkage_name: _ZN5AlphaaSERKS_ > DW_AT_type : > DW_AT_artificial : 1 > DW_AT_declaration : 1 > > With the new gcc HEAD, the dwarf-2 info looks like this: > > <2>: Abbrev Number: 21 (DW_TAG_subprogram) > DW_AT_sibling : > DW_AT_name : (indirect string, offset: 0x999): operator= > DW_AT_type : > 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 > > ... > * 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