From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 51145 invoked by alias); 7 Feb 2018 16:51:02 -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 51127 invoked by uid 89); 7 Feb 2018 16:51:02 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=H*i:sk:b0f780d, H*f:sk:b0f780d X-HELO: mail-io0-f170.google.com Received: from mail-io0-f170.google.com (HELO mail-io0-f170.google.com) (209.85.223.170) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 07 Feb 2018 16:51:00 +0000 Received: by mail-io0-f170.google.com with SMTP id m11so2696911iob.2 for ; Wed, 07 Feb 2018 08:51:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ttizaV0pobNqdbuR1MFA9L/cBlAUVwlw16j7krZlN/M=; b=I628oR+oyqpNLuYeJ8Nk45X7yUk/StBwSTDH9x1PCjqSlrbjyiGndfOc/0EUF8FRnH 1DfKAdSK6vmjJY9YX5lZ9XsbRuq7JpCkORfY9O6QRlsa+ydrfFtx2Ud5u9XXv9EhwI8k uGScBkGFbI/ZfNSXh2UVrAtroMSuOl0bWxS+JzMGG3rSo088fwYEh4xBMg9ftNxnzz+7 NEtlqtlPSXizEkMtpxiLXI4kH6kH4SnuD7V9UKJir+y4B7fuSCWEpWXI1fD3kTqFlU+Y EpPIPC6/6HJwmFVwVtdsDBtEvg5Lig+jSGEJZqaR25xkm2xOGYRVz0x0EZ+3h+jdfn2t YRoQ== X-Gm-Message-State: APf1xPDccONMJYnIfNVzRRsWGrirRzmtz4VpOaY/B5bkUuULEP9CUHb7 V9IuY6cAnzTC3O9V9otgpWOZUHitA8+AX3yCovc= X-Google-Smtp-Source: AH8x225geNtknwprX8/2uKa3eT4zJ+BYl5oBeB50SNjbGibsYipdJADEUPowHNiPGk8N/nL3A5VSUN94y1FKbo7y0ss= X-Received: by 10.107.169.211 with SMTP id f80mr7688461ioj.275.1518022258851; Wed, 07 Feb 2018 08:50:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.50.198 with HTTP; Wed, 7 Feb 2018 08:50:58 -0800 (PST) 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> From: Jonathan Wakely Date: Wed, 07 Feb 2018 16:51:00 -0000 Message-ID: Subject: Re: gdb 8.x - g++ 7.x compatibility To: Simon Marchi Cc: Michael Matz , Daniel Berlin , Martin Sebor , Manfred , gdb@sourceware.org, GCC Content-Type: text/plain; charset="UTF-8" X-SW-Source: 2018-02/txt/msg00062.txt.bz2 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.