From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 96006 invoked by alias); 7 Feb 2018 17:03:35 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 95994 invoked by uid 89); 7 Feb 2018 17:03:34 -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=ham version=3.3.2 spammy=H*f:sk:Ks-cQw9, H*i:sk:Ks-cQw9, Hx-languages-length:1721 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:03:33 +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 w17H3QYA023464 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 7 Feb 2018 12:03:31 -0500 Received: by simark.ca (Postfix, from userid 112) id A87991E759; Wed, 7 Feb 2018 12:03:26 -0500 (EST) Received: from simark.ca (localhost [127.0.0.1]) by simark.ca (Postfix) with ESMTP id 760981E520; Wed, 7 Feb 2018 12:03:25 -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:03: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> Message-ID: <0f519031e0a603b18788589d5c1700d3@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:03:26 +0000 X-IsSubscribed: yes X-SW-Source: 2018-02/txt/msg00063.txt.bz2 On 2018-02-07 11:50, Jonathan Wakely wrote: > On 7 February 2018 at 16:36, Simon Marchi wrote: >> On 2018-02-07 11:26, Michael Matz wrote: >>> >>> Hi, >>> >>> On Wed, 7 Feb 2018, Simon Marchi wrote: >>> >>>> This addresses the issue of how to do good software design in GDB to >>>> support different producers cleanly, but I think we have some issues >>>> even before that, like how to support g++ 7.3 and up. I'll try to >>>> summarize the issue quickly. It's now possible to end up with two >>>> templated classes with the same name that differ only by the >>>> signedness >>>> of their non-type template parameter. One is Foo and the >>>> other >>>> is Foo (the 10 is unsigned). Until 7.3, g++ would >>>> generate names like Foo<10> for the former and names like Foo<10u> >>>> for >>>> the later (in the DW_AT_name attribute of the classes' DIEs). Since >>>> 7.3, >>>> it produces Foo<10> for both. >>> >>> >>> Yeah, gdb needs a way to lookup types by name, and since the change >>> DW_AT_name can't be used for this anymore. Either that needs to be >>> fixed/reverted, or we do the more obvious thing: since types in C++ >>> have >>> linkage it makes sense to add the linkage (i.e. mangled) name to the >>> types >>> DIE using the traditional DW_AT_MIPS_linkage_name. >>> >>> That latter solution would have the advantage that you don't need to >>> demangle anything anymore. From vtable you get to typeinfo, from >>> there >>> for typeinfo name, and that contains the mangled type name (without >>> _Z >>> prefix). >> >> >> But do struct/classes have mangled names? > > Yes. Interesting. What do they look like, and in what context do they appear? Simon