From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29456 invoked by alias); 7 Feb 2018 17:20:38 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 29373 invoked by uid 89); 7 Feb 2018 17:20:37 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.2 spammy=H*f:sk:HdJE4DE, H*f:SLT4cDo, H*i:SLT4cDo, H*i:sk:HdJE4DE X-HELO: smtp.polymtl.ca Received: from smtp.polymtl.ca (HELO smtp.polymtl.ca) (132.207.4.11) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 07 Feb 2018 17:20:36 +0000 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id w17HKTLM003213 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 7 Feb 2018 12:20:34 -0500 Received: by simark.ca (Postfix, from userid 112) id DD41E1E75A; Wed, 7 Feb 2018 12:20:29 -0500 (EST) Received: from simark.ca (localhost [127.0.0.1]) by simark.ca (Postfix) with ESMTP id 49A531E520; Wed, 7 Feb 2018 12:20:28 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 07 Feb 2018 17:20:00 -0000 From: Simon Marchi To: Jonathan Wakely Cc: Michael Matz , Daniel Berlin , Martin Sebor , Manfred , gdb@sourceware.org, GCC Subject: Re: gdb 8.x - g++ 7.x compatibility In-Reply-To: References: <1517667601.3405.123.camel@gnu.org> <1b58e2df-5425-4f22-510c-d2e9f51040ba@polymtl.ca> <39845077-6bdf-f60d-9bfc-a491e7fa4fc7@gmail.com> <132fbd97-4f0d-020f-1c0f-1d4097800233@polymtl.ca> <6da16f7c-4801-4c57-2197-271db491a88f@gmail.com> <6394368bca446f08119118a0f88a30b7@polymtl.ca> <0f519031e0a603b18788589d5c1700d3@polymtl.ca> Message-ID: <5a58deaaf993c5dc275386e5cd89cc37@polymtl.ca> X-Sender: simon.marchi@polymtl.ca User-Agent: Roundcube Webmail/1.3.4 X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Wed, 7 Feb 2018 17:20:30 +0000 X-SW-Source: 2018-02/txt/msg00081.txt.bz2 On 2018-02-07 12:08, Jonathan Wakely wrote: > Why would they not have a mangled name? > >> Interesting. What do they look like, and in what context do they >> appear? > > Anywhere you need a name for linkage purposes, such as in a function > signature, or as a template argument of another type, or in the > std::type_info::name() for the type etc. etc. > > $ g++ -o test.o -c -x c++ - <<< 'struct X {}; void f(X) {} > template struct Y { }; void g(Y) {}' && nm > --defined-only test.o > 0000000000000000 T _Z1f1X > 0000000000000007 T _Z1g1YI1XE > > The mangled name for X is "X" and the mangled name for Y is "YI1XE" > which includes the name "X". > > This isn't really on-topic for solving the GDB type lookup problem > though. Ah ok, the class name appears mangled in other entities' mangled name. But from what I understand there's no mangled name for the class such that echo | c++filt outputs the class name (e.g. "Foo<10>"). That wouldn't make sense, since there's no symbol for the class itself. Simon