From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13292 invoked by alias); 4 Jul 2004 11:19:05 -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 13283 invoked from network); 4 Jul 2004 11:19:03 -0000 Received: from unknown (HELO tisch.mail.mindspring.net) (207.69.200.157) by sourceware.org with SMTP; 4 Jul 2004 11:19:03 -0000 Received: from user-119a90a.biz.mindspring.com ([66.149.36.10] helo=berman.michael-chastain.com) by tisch.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1Bh51T-00023O-00 for gdb@sources.redhat.com; Sun, 04 Jul 2004 07:19:03 -0400 Received: by berman.michael-chastain.com (Postfix, from userid 502) id 73AEA4B104; Sun, 4 Jul 2004 07:19:19 -0400 (EDT) To: gdb@sources.redhat.com Subject: gcc HEAD dwarf-2, synthetic methods no longer public, gdb confused Message-Id: <20040704111919.73AEA4B104@berman.michael-chastain.com> Date: Sun, 04 Jul 2004 11:19:00 -0000 From: mec.gnu@mindspring.com (Michael Elizabeth Chastain) X-SW-Source: 2004-07/txt/msg00021.txt.bz2 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. 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. 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. I can't find anything in TC++PL about the scope of synthesized methods. But it seems reasonable to me that they no longer have DW_AT_external and a DW_AT_MIPS_linkage_name. I haven't looked inside dwarf2read.c yet. Somehow the change in debug info is causing it to associate the name 'Alpha' with the synthesized copy ctor rather than with the class. operator= has the changed debug info, but gdb thinks that 'Alpha' is associated with the synthesized copy ctor. Something strange is happening in the dwarf-2 reader. This causes a FAIL in class2.exp on the "print (B *) abp" test, because gdb thinks that "B" is not the name of s class. It probably causes some of the other FAIL's I have here as well. So my questions are: ... is this good dwarf-2 info? ... if so, can we fix the dwarf-2 reader to handle it? ... if not, i will file a gcc pr Michael C