From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 127745 invoked by alias); 7 Feb 2018 15:16:03 -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 127602 invoked by uid 89); 7 Feb 2018 15:16:02 -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,FREEMAIL_FROM,KAM_SHORT,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=unavailable version=3.3.2 spammy=H*f:sk:6394368, onetoone, one-to-one, H*i:sk:03b08ef X-HELO: mail-it0-f53.google.com Received: from mail-it0-f53.google.com (HELO mail-it0-f53.google.com) (209.85.214.53) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 07 Feb 2018 15:15:56 +0000 Received: by mail-it0-f53.google.com with SMTP id h129so2615816ita.2 for ; Wed, 07 Feb 2018 07:15: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=gZMq49sDHCh+yexwa+E9uxLXDWQIcgUYnS2ej8wgEUM=; b=fiSRwDjvhLTXSz10RBT1QaVoQVNuG2AMAkKN2JckqbFRSksxkf+9zOu8w5d4s4PMCC SAUWDND9H/Q7J5Vyi4bd+PDXxgU7sqFL8AcKOxtzdIHDZUA07k5pU7gyq4b6S1wrGUbG CRB0o9DiJrC5EQ0eqiJSfAJWPTSW3OxcZ+BcGYGKxDM69CaC/0s13K/3Hig1LWPAe7kD sa4mz8PLIgZLmegA4rHm0sDMBrRvDrnteSa/ibgXc7YvOTI7gRNGDZiiTAjunyc8AzrO YAO7yGABatlatVGG/+zp3KOf0jfccNsKILm+il4ISLRsX/Lh+0O8KVtTA8Ddi21xCTLq Iz/w== X-Gm-Message-State: APf1xPBeMZIPUoQjKbdHVf7WFOm4PJ6pAcVYR3LjyJl1zUb/EZiIuoHu g4nb4rYulLg551bul80vodZK9O/sKEsooeZoHq1LPTud X-Google-Smtp-Source: AH8x225JkirkuVHCC5YowZm6a132MwTpsEhr48HlpxqPtnNYp1WIGpmT58tTrju9g/nGgp+G7AMZ0O/WJeWOlvivnuw= X-Received: by 10.36.28.82 with SMTP id c79mr8727390itc.128.1518016555012; Wed, 07 Feb 2018 07:15:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.50.198 with HTTP; Wed, 7 Feb 2018 07:15:54 -0800 (PST) In-Reply-To: <03b08ef2-e765-5dc2-f390-00c31e74c5ec@gmail.com> 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> <03b08ef2-e765-5dc2-f390-00c31e74c5ec@gmail.com> From: Jonathan Wakely Date: Wed, 07 Feb 2018 15:16:00 -0000 Message-ID: Subject: Re: gdb 8.x - g++ 7.x compatibility To: Manfred Cc: gdb@sourceware.org, GCC Content-Type: text/plain; charset="UTF-8" X-SW-Source: 2018-02/txt/msg00057.txt.bz2 On 7 February 2018 at 15:07, Manfred wrote: > > > On 02/07/2018 02:44 PM, Simon Marchi wrote: >> >> On 2018-02-07 02:21, Daniel Berlin wrote: >>> >>> As the person who, eons ago, wrote a bunch of the the GDB code for this >>> C++ >>> ABI support, and as someone who helped with DWARF support in both GDB and >>> GCC, let me try to propose a useful path forward (in the hopes that >>> someone >>> will say "that's horrible, do it this instead") >>> >>> Here are the constraints i believe we are working with. >>> >>> 1. GDB should work with multiple DWARF producers and multiple C++ >>> compilers >>> implementing the C++ ABI >>> 2. There is no canonical demangled format for the C++ ABI >>> 3. There is no canoncial target demangler you can say everyone should use >>> (and even if there was, you don't want to avoid debugging working because >>> someone chose not to) >>> 4. You don't want to slow down GDB if you can avoid it >>> 5. Despite them all implementation the same ABI, it's still possible to >>> distinguish the producers by the producer/compiler in the dwarf info. >>> >>> Given all that: >>> >>> GDB has ABI hooks that tell it what to do for various C++ ABIs. This is >>> how >>> it knows to call the right demangler for gcc v3's abi vs gcc v2's abi. >>> and >>> handle various differences between them. >>> >>> See gdb/cp-abi.h >>> >>> The IMHO, obvious thing to do here is: Handle the resulting demangler >>> differences with 1 or more new C++ ABI hooks. >>> Or, introduce C++ debuginfo producer hooks that the C++ ABI hooks use if >>> folks want it to be separate. >>> >>> Once the producer is detected, fill in the hooks with a set of functions >>> that does the right thing. >>> >>> I imagine this would also clean up a bundle of hacks in various parts of >>> gdb trying to handle these differences anyway (which is where a lot of >>> the >>> multiple symbol lookups/etc that are often slow come from. >>> If we just detected and said "this is gcc 6, it behaves like this", we >>> wouldn't need to do that) >>> >>> In case you are worried, you will discover this is how a bunch of stuff >>> is >>> done and already contains a ball of hacks. >>> >>> Using hooks would be, IMHO, a significant improvement. >> >> >> Hi Daniel, >> >> Thanks for chiming in. >> >> 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. >> >> When GDB wants to know the run time type of an object, it fetches the >> pointer to its vtable, does a symbol lookup to get the linkage name and >> demangles it, which gives a string like "vtable for Foo<10>" or "vtable for >> Foo<10u>". It strips the "vtable for " and uses the remainder to do a type >> lookup. Since g++ 7.3, you can see that doing a type lookup for Foo<10> may >> find the wrong type, and doing a lookup for Foo<10u> won't find anything. >> >> So the problem here is how to uniquely identify those two classes when we >> are doing this run-time type finding operation (and probably in other cases >> too). >> >> Simon > > > Hi all, > > In the perspective of "type identity", the way I see it the issue has a few > parts: > > 1) How GCC compiles such templates > 2) How GCC emits debugging information via -g > 3) How such information is interpreted (and merged with the compiled code) > by GDB > > Regarding 1) and 2), IMHO I think that there should be a one-to-one > relationship between the compiled code output and debug info: > > This means that if GCC compiles such templates into two different > classes[1], it should generate two different type identifiers. What do you mean by "such templates"? There have been several different examples in the thread, which should be handled differently. > Conversely, if it compiles the templates into the same class, then a single > identifier should be emitted for the single class compiled. > (This goes besides the point of what the standard dictates[2]) > > If I understand it right, currently the issue is that gcc emits two types > with the same debug identifier. > > Regarding 3), I think that after 1) and 2) are set up, GDB should be able to > find the correct type definition (using the most appropriate design choice). > > Hope this helps, Not really :-) You're basically just saying "GCC and GDB should do the right thing" which is a statement of the obvious. > [1] According to the findings of Simon, this appears to be the case with > clang, older GCC, and current GCC master. Do I understand this right? As I said above, it's not clear what you're referring to. > [2] About handling both templates instantiation as a single class, I think > that if GCC wants to emit a single class, then its argument type > instantiation should be well-definined,i.e. independent of the order of > declaration - see the findings from Simon earlier in this thread where you > could get the program output either -10 or 4294967286 depending on which > declaration would come first. That's just a GCC 7 bug in the handling of auto template parameters, see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79092 It's not really relevant here, and is already fixed on trunk.