From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2456 invoked by alias); 7 Feb 2018 17:08:59 -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 2395 invoked by uid 89); 7 Feb 2018 17:08:58 -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= X-HELO: mail-io0-f171.google.com Received: from mail-io0-f171.google.com (HELO mail-io0-f171.google.com) (209.85.223.171) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 07 Feb 2018 17:08:57 +0000 Received: by mail-io0-f171.google.com with SMTP id f34so2739174ioi.13 for ; Wed, 07 Feb 2018 09:08:56 -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=yUjeKCT5cG9HIMKY94H7TWAM6m78l7vUy7/TMRi3D7g=; b=oR8KRmbmopLKCdmDS1vlS/tskY4YcAccAlrrQeKPPfqXsG8j+Kqy5/zZ3uide0sBh1 BSSGSgosdSrcl/gXyYsvkIAyfHdQhfd5lm8vVZ8ebnzWskoAkhNF0GmHkiPUG/Yv3Yhu Rtai6rAIUFCXcb8ik1p2+Rqf+52XR95fmNmQONaiM+PgIG2x1X8Zooc6okIO93J2gO3O Kv//SmfhNoBZzErR9fABsBdNLJyID2favyiYQKQFWiBX9ZjyH7HGHccsAvfproMVtDEP ITVQK0aoc9yt3wX9gcNscZxVqE1FU3ZLksCxUvvGshE4kmuNTpE0OlI0hCLFRyTKrgPy 47zA== X-Gm-Message-State: APf1xPBA6zAxhn5foCGCozJBZf1ZiRIXHPTLsL0S4sIsmyzV4Ckw685P JznaJBJuTtuxBQimsLSa2xNrGoUd995kJ8KMCUI= X-Google-Smtp-Source: AH8x224IrIgYh9V/8tzSrIvEW0HFdSvBH/reBp1ky4P1oSfro7XLnB5sJsSd3KQI9lTqoP5IF1jMki9FJ35Y4KS1yBc= X-Received: by 10.107.169.211 with SMTP id f80mr7759461ioj.275.1518023335442; Wed, 07 Feb 2018 09:08:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.50.198 with HTTP; Wed, 7 Feb 2018 09:08:55 -0800 (PST) In-Reply-To: <0f519031e0a603b18788589d5c1700d3@polymtl.ca> 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> From: Jonathan Wakely Date: Wed, 07 Feb 2018 17:08: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/msg00065.txt.bz2 On 7 February 2018 at 17:03, Simon Marchi wrote: > 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. 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.