From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31483 invoked by alias); 4 May 2011 17:57:50 -0000 Received: (qmail 31471 invoked by uid 22791); 4 May 2011 17:57:48 -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 17:57:31 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p44HvSYY025963 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 4 May 2011 13:57:28 -0400 Received: from host1.jankratochvil.net (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p44HvQUo010907 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 May 2011 13:57:28 -0400 Received: from host1.jankratochvil.net (localhost [127.0.0.1]) by host1.jankratochvil.net (8.14.4/8.14.4) with ESMTP id p44HvQkj006420; Wed, 4 May 2011 19:57:26 +0200 Received: (from jkratoch@localhost) by host1.jankratochvil.net (8.14.4/8.14.4/Submit) id p44HvP4G006418; Wed, 4 May 2011 19:57:25 +0200 Date: Wed, 04 May 2011 17:57: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: <20110504175725.GA5907@host1.jankratochvil.net> References: <20110504150846.GA27179@host1.jankratochvil.net> <201105041732.p44HWhvj008763@d06av02.portsmouth.uk.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201105041732.p44HWhvj008763@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/msg00104.txt.bz2 On Wed, 04 May 2011 19:32:43 +0200, Ulrich Weigand wrote: > Jan Kratochvil wrote: > + For full symbols return its demangled form of view of the linker, that is > + with typedefs and toplevel const/volatile qualifiers of parameters removed, > + for `f(int_typedef const)' it is `f(int)'. If no typedefs/qualifiers are > + in use it's the same as SYMBOL_NATURAL_NAME. The mangled symbol name is not > + available for full symbols. */ > > is not fully accurate either. As far as I can tell, that *is* true for > symbols read in by the DWARF reader. However, for symbols read in by > the stabs reads (or any of the others), SYMBOL_LINKAGE_NAME still refers > to the mangled name ... (Which strikes me as quite odd in the first > place; how is common code supposed to use this field?) Thanks for the update. Yes, SYMBOL_LINKAGE_NAME is somehow broken now for many use cases, I do not know myself what is the best way out now. > > With a GCC debug/ fix it should work. Do you agree with its filing? > > It seems that by now we have agreement that GCC is correct here. I haven't found in the C++ spec. why it isn't a different way but that is out of topic here, the truth is the current linkage name is `C::C()'. > So I guess I see two options remaining: > > - Code a test that compares class name and (demangled) function name, but > explicitly removes template instance parameters first I find it as a good idea. > - Have the symbol reader call is_constructor_name on the mangled name while > it is still available, and store that information somewhere in the type > information The mangled name is never read (processed) from the DWARF file now. Thanks, Jan