From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25813 invoked by alias); 4 May 2011 15:09:13 -0000 Received: (qmail 25805 invoked by uid 22791); 4 May 2011 15:09:12 -0000 X-SWARE-Spam-Status: No, hits=-5.6 required=5.0 tests=AWL,BAYES_00,KAM_STOCKGEN,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 04 May 2011 15:08:51 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p44F8nc9002492 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 4 May 2011 11:08:49 -0400 Received: from host1.jankratochvil.net (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p44F8l7D032534 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 May 2011 11:08:49 -0400 Received: from host1.jankratochvil.net (localhost [127.0.0.1]) by host1.jankratochvil.net (8.14.4/8.14.4) with ESMTP id p44F8lw4028032; Wed, 4 May 2011 17:08:47 +0200 Received: (from jkratoch@localhost) by host1.jankratochvil.net (8.14.4/8.14.4/Submit) id p44F8kWw028011; Wed, 4 May 2011 17:08:46 +0200 Date: Wed, 04 May 2011 15:09:00 -0000 From: Jan Kratochvil To: Ulrich Weigand Cc: gdb-patches@sourceware.org, Keith Seitz Subject: Re: Is physname mangled or not? (PR c++/8216) Message-ID: <20110504150846.GA27179@host1.jankratochvil.net> References: <201105031858.p43IwneJ006235@d06av02.portsmouth.uk.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201105031858.p43IwneJ006235@d06av02.portsmouth.uk.ibm.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2011-05/txt/msg00095.txt.bz2 On Tue, 03 May 2011 20:58:49 +0200, Ulrich Weigand wrote: > - For template classes, the method name of a constructor does > *not* contain the template instance type list, while the type > name does, and thus the strcmp fails <1><55>: Abbrev Number: 6 (DW_TAG_class_type) <56> DW_AT_name : (indirect string, offset: 0xb): C <2><61>: Abbrev Number: 7 (DW_TAG_subprogram) <63> DW_AT_name : C <68> DW_AT_declaration : 1 <69> DW_AT_object_pointer: <0x71> <3><71>: Abbrev Number: 4 (DW_TAG_formal_parameter) <72> DW_AT_type : <0x80> <76> DW_AT_artificial : 1 <2><78>: Abbrev Number: 8 (DW_TAG_template_type_param) <79> DW_AT_name : T <7b> DW_AT_type : <0x119> (less important attributes removed). This is IMO a GCC debug/ bug, shouldn't <63> DW_AT_name be `C'? > - The is_constructor_name C++ ABI callback actually fails > *always*. This is because it works only if it gets a > *mangled* name as input, but TYPE_FN_FIELD_PHYSNAME returns > a demangled name (at least with dwarf2read.c) ... This physname change broke more issues, thanks for finding this one. The change I described in the bottom patch of: Re: [RFA] Typedef'd method parameters [2/4] http://sourceware.org/ml/gdb-patches/2011-04/msg00524.html that is the part: The mangled symbol name is not available for full symbols. */ #define SYMBOL_LINKAGE_NAME(symbol) (symbol)->ginfo.name Although a similar comment should be now also at: TYPE_FN_FIELD_PHYSNAME The other physname regressions of belonging to this no-longer-mangled category: New: regression by physname: PE32 prologue skip vs. static initializers http://sourceware.org/bugzilla/show_bug.cgi?id=12680 New: physname regression: set print demangle off http://sourceware.org/bugzilla/show_bug.cgi?id=12707 > So I guess my question is, how is this supposed to work? Should > is_constructor_name accept demangled names? It cannot - it does not know the type name, does it? > Should there be some generic routine that instead tests a demangled name for > whether it is a constructor (or destructor)? With a GCC debug/ fix it should work. Do you agree with its filing? Thanks, Jan