From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 98877 invoked by alias); 7 Feb 2018 17:04:09 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 98859 invoked by uid 89); 7 Feb 2018 17:04:09 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: =?ISO-8859-1?Q?No, score=3.1 required=5.0 tests=BAYES_00,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=no version=3.3.2 spammy=H*r:sk:g18-v6s, up.=c2, lookup.=c2, quickly.=c2?= X-HELO: mail-pl0-f47.google.com Received: from mail-pl0-f47.google.com (HELO mail-pl0-f47.google.com) (209.85.160.47) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 07 Feb 2018 17:04:07 +0000 Received: by mail-pl0-f47.google.com with SMTP id g18-v6so385854plo.7 for ; Wed, 07 Feb 2018 09:04:07 -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=xaUGVs//yGX6lH+VQeZSfpUiuH97okZUuj8vJZ5sQNw=; b=XbAxf8uTGbkyIsedVWsAHHDJ62+kXeoJI39e1xkIn9cIjjQE3L/29oAWwVhZvRcl/3 AC4+xHxTTF7bkA56snzZFwX9WiTpNJIy7dYd9IEDaYLJeskQKUeJOdfiyCPRCIec82ix jhROXz8RldW5UBMN14DnCHw1xV80I1xBBX0hu1wDzFdZp2CcyU3Y1pv5fEZv84EsDm1k KCl8iiRGca72A2QultFwnyab2pQ51nGqrdSdwByL4Wwd4Cin1YJ7/tzxREeQVK10Mkuu 3e279roF7swtSv7FXjoS6VpcjFwk7/bcQJLjsLwnxriJAiVwucQxaPsX501/isfX8qNq 5eTA== X-Gm-Message-State: APf1xPA0YH5NNAEi71yxgVIgAR/hg8/h2QBFjgEBPF6ANyKojMato7Yn 2YSupk5Bsz0mhATtsMflRIxD2pOsBRIrc7eLG1CAfg== X-Google-Smtp-Source: AH8x226t6PLGi7s4CJxH8F1L9RbdSeGwryjBoos2eGwe8s9LMEXZqiWk84lFb5a1ayjsQCvnCTdKblCi+puNXXHMfBA= X-Received: by 2002:a17:902:3124:: with SMTP id w33-v6mr6600400plb.356.1518023045233; Wed, 07 Feb 2018 09:04:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.148.198 with HTTP; Wed, 7 Feb 2018 09:04:04 -0800 (PST) In-Reply-To: <6394368bca446f08119118a0f88a30b7@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> From: Daniel Berlin Date: Wed, 07 Feb 2018 17:04:00 -0000 Message-ID: Subject: Re: gdb 8.x - g++ 7.x compatibility To: Simon Marchi Cc: Martin Sebor , Manfred , gdb@sourceware.org, GCC Content-Type: text/plain; charset="UTF-8" X-SW-Source: 2018-02/txt/msg00076.txt.bz2 On Wed, Feb 7, 2018 at 5:44 AM, 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. They are, IMHO, the same. > 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. Yup. > 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, Yes, this is code i wrote :) > 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, Certainly if you can't distinguish the types you are screwed, but this is not the only way to find this type. This was in fact, the first hack i thought up to make it work because the ABI was not entirely fully formed at the time, and the debug info did not have fully qualified names. Here is a different way that should produce more consistent results. Find the linker symbol look up the symbol in the dwarf info by address. This will give you the vtable type debug info. Look at the name attribute of the debug info, which should already be demangled. Strip the "vtable for" from that. Look that up. This avoids the problem of the demangler gdb is using getting a different name than the producer used. It also should always give you the right one. If the producer calls the type "vtable fo Foo<2u>" here and "Foo<2>" elsewhere, yes, that's a bug. It should be consistent. If there are multiple types named Foo<2u>, DWARF needs to be extended to allow a pointer from the vtable debug info to the class type debug info (unless they already added one). Then you would do *no* symbol lookups, you'd follow that pointer (gdb would add it to the symbol_info structure) > and doing a lookup for Foo<10u> won't find anything. > Correct. This stripping is a hook that does the stripping and lookup in gnuv3_rtti_type. That is not the only way yo to it. > > 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 >