From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 65548 invoked by alias); 7 Feb 2018 13:44:39 -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 65525 invoked by uid 89); 7 Feb 2018 13:44:39 -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,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=UD:cp-abi.h, v3s, canoncial, eons X-HELO: smtp.polymtl.ca Received: from smtp.polymtl.ca (HELO smtp.polymtl.ca) (132.207.4.11) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 07 Feb 2018 13:44:37 +0000 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id w17DiUVI029464 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 7 Feb 2018 08:44:35 -0500 Received: by simark.ca (Postfix, from userid 112) id B32CB1E75A; Wed, 7 Feb 2018 08:44:30 -0500 (EST) Received: from simark.ca (localhost [127.0.0.1]) by simark.ca (Postfix) with ESMTP id 461681E4F4; Wed, 7 Feb 2018 08:44:29 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 07 Feb 2018 13:44:00 -0000 From: Simon Marchi To: Daniel Berlin Cc: Martin Sebor , Manfred , gdb@sourceware.org, GCC Subject: Re: gdb 8.x - g++ 7.x compatibility 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> Message-ID: <6394368bca446f08119118a0f88a30b7@polymtl.ca> X-Sender: simon.marchi@polymtl.ca User-Agent: Roundcube Webmail/1.3.4 X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Wed, 7 Feb 2018 13:44:30 +0000 X-SW-Source: 2018-02/txt/msg00066.txt.bz2 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