From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 96893 invoked by alias); 7 Feb 2018 15:07:48 -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 96871 invoked by uid 89); 7 Feb 2018 15:07:47 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,MISSING_HEADERS,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=no version=3.3.2 spammy=H*i:sk:6394368, H*f:sk:6394368 X-HELO: mail-wm0-f41.google.com Received: from mail-wm0-f41.google.com (HELO mail-wm0-f41.google.com) (74.125.82.41) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 07 Feb 2018 15:07:46 +0000 Received: by mail-wm0-f41.google.com with SMTP id j21-v6so23059622wmh.1 for ; Wed, 07 Feb 2018 07:07:45 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=30UUrWxV8mctEFn/Bk9MUveLMgmBBSCdpktDP2ujAzE=; b=XYO/Jy74s25Q5yMbiGpm8S4iAdErISxS2wt9lRlJ3PyfsixKA98nPlTAeVtEvwUdXv 5fd5ldBkTArHmhxLWdovDuaJdJ5+bHkaeQgv0krtBUm1bWSscdUDVwFn5AIP6xfT4whv L/dzRwsVkewQp1idQbSOLNeyHrVQgP+BXMahmKRfBkDit8eYIkFhaljTSRH+j5bPFRF6 CS/fhM8jHWytA5Jta6wr5GgtNHlIk3nGI1WNvCvRtCiyDgt1paETlETPDLWKI0BGKbC+ IplSmpFFhj+tAWH1PZ9c2rIKUcms9FciMF3ylY9UOQC0hguIGSLE34DDAxzP37BmdBCr X41g== X-Gm-Message-State: APf1xPBrpDW9i+Bz8Wvtf6rD9PEviPde7sGsvCxDrpiKZ2CWxoyZRJYx gmOvi8OJotOqtaqiVU1lVDfriQ== X-Google-Smtp-Source: AH8x224OuE3hiRqtFy2npzt5hyiZM1KUh8JPJRU/yI9H411xa8El1WSbEi7BYXJGxcgeCVzcasXUZg== X-Received: by 10.28.66.199 with SMTP id k68mr5215797wmi.104.1518016063961; Wed, 07 Feb 2018 07:07:43 -0800 (PST) Received: from pcx.eikon.lan ([151.58.14.242]) by smtp.googlemail.com with ESMTPSA id l92sm2661978wrc.31.2018.02.07.07.07.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Feb 2018 07:07:43 -0800 (PST) Subject: Re: gdb 8.x - g++ 7.x compatibility Cc: gdb@sourceware.org, GCC 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: Manfred Message-ID: <03b08ef2-e765-5dc2-f390-00c31e74c5ec@gmail.com> Date: Wed, 07 Feb 2018 15:07:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <6394368bca446f08119118a0f88a30b7@polymtl.ca> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2018-02/txt/msg00056.txt.bz2 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. 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, Manfred [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? [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.