From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 101492 invoked by alias); 7 Feb 2018 16:19:56 -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 101472 invoked by uid 89); 7 Feb 2018 16:19:55 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=no version=3.3.2 spammy=mx2927gmailcom, H*i:sk:RHUFGjO, H*f:sk:RHUFGjO, mx2927@gmail.com X-HELO: mail-wm0-f48.google.com Received: from mail-wm0-f48.google.com (HELO mail-wm0-f48.google.com) (74.125.82.48) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 07 Feb 2018 16:19:53 +0000 Received: by mail-wm0-f48.google.com with SMTP id g1so4189915wmg.2 for ; Wed, 07 Feb 2018 08:19:53 -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:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ckan+n+ZvHGqDGI/NSf9yCvGwG6Y3UziRnGEkC2fSSg=; b=O2xRmSD9Wnzxaze8VqbQoOp4jLWAtsQIQA84En/EZQ6+EKjPZjHGYSMB1+yWKZUpsy TULq6DozwcV9lse4U7oDcM8Wo9SfRE8SLiatuJsIoVsgQaiBEQj8ZpWOFm7oF76pkHfn B5LrP+3eDAEq+SHxSDlSs0JeoBk2lYRa2fTeIpK+8VOXyxa7w8LzDexC2HhZUmkwj5ER +vpdCX/0QZH2T5UdUF9PpaF8l3AY/CKOiuHKJ0/FHnE1bgbzjMgfFshnM59ZK82Mm6HD MA0S7XQZhRCqjWk91PKy0j2dc7x3xxlcjEznef2prMSnBGoW2QC6wYQbyXP9iwJEY8D/ y4BA== X-Gm-Message-State: APf1xPDvljwsYYhpNnlVzSvkS5U9JRkhHx1ILGrere/WJDB7ZnsBytrd nHLSa45lYLaKCRq+AEuhuqsn2A== X-Google-Smtp-Source: AH8x2269ojgbYgt45iWol7H45r+sc+Ebew8WEO2Ws4VR4rqV/wzlzLyC8FNvC2MuuKWrP3gNRbcYkQ== X-Received: by 10.28.234.200 with SMTP id g69mr4828361wmi.137.1518020391344; Wed, 07 Feb 2018 08:19:51 -0800 (PST) Received: from [192.168.0.155] ([151.58.14.242]) by smtp.googlemail.com with ESMTPSA id d17sm1660917wrc.38.2018.02.07.08.19.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Feb 2018 08:19:50 -0800 (PST) Subject: Re: gdb 8.x - g++ 7.x compatibility To: 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> <03b08ef2-e765-5dc2-f390-00c31e74c5ec@gmail.com> From: Manfred Message-ID: <7998236b-17bd-e20a-7ec6-45b85c235733@gmail.com> Date: Wed, 07 Feb 2018 16:19:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2018-02/txt/msg00059.txt.bz2 On 2/7/2018 4:15 PM, Jonathan Wakely wrote: > On 7 February 2018 at 15:07, Manfred wrote: >> >> >> On 02/07/2018 02:44 PM, 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. >>> >>> 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. From Roman 2/3/2018 #include struct base { virtual void print() = 0; }; template< auto IVAL> struct foo : base { decltype(IVAL) x = -IVAL; void print() override { std::cout << x << std::endl; }; }; From Simon 2/4/2018 base * fi = new foo<10>(); base * fu = new foo<10u>(); You are right that the original thread was started by Roman with: struct base { virtual ~base(){} }; template< int IVAL, unsigned UVAL, unsigned long long ULLVAL> struct derived : base { int x = IVAL + + UVAL + ULLVAL; }; > >> 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 :-) Sorry for that :-) > > You're basically just saying "GCC and GDB should do the right thing" > which is a statement of the obvious. Besides the obvious, the main point was: "IMHO I think that there should be a one-to-one relationship between the compiled code output and debug info" and: "If I understand it right, currently the issue is that gcc emits two types with the same debug identifier." Which was an attempt to help by making obvious what I understood was going wrong. > > >> [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. I had in mind foo<10> and foo<10u> After your remark, I realize I should have left out "older GCC" because 'auto' does not apply to it - older GCC dealt with the initial example: template< int IVAL, unsigned UVAL, unsigned long long ULLVAL> > >> [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. > Thanks for pointing this out. If I understand it correctly, the solution of the bug is that foo<10> and foo<10u> result in two different classes (according to your comment #1 in the bug, which by the way I am not sure how it plays with the wording of the standard, but that's beyond gdb compatibility) Has -g type identification been differentiated too? Getting back to auto/non-auto template arguments, I understand they are different subjects, still, though, type identification in debug info applies to both. I am just a C++ gcc and gdb user, so I am missing their internals. I think I'll keep quiet if this leads to unintentional noise.