From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26723 invoked by alias); 3 Feb 2018 18:36:04 -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 26617 invoked by uid 89); 3 Feb 2018 18:36:04 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.1 required=5.0 tests=AWL,BAYES_20,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=no version=3.3.2 spammy=gmt08, GMT08, GMT-08, gmt-08 X-HELO: mail-wm0-f53.google.com Received: from mail-wm0-f53.google.com (HELO mail-wm0-f53.google.com) (74.125.82.53) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 03 Feb 2018 18:36:02 +0000 Received: by mail-wm0-f53.google.com with SMTP id 141so18441807wme.3 for ; Sat, 03 Feb 2018 10:36:02 -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=Ei8kDV4YRqYMF5KF1g9J8FQvdhzMSck1U7P4Swt4svU=; b=GV9JKHnmjZlHbXCEYwf8wUieYG5VpJRJOE1Pnk1OOplA00uX56VhK9vFIQiL8yfSoe VwFWIh1xi2Crdo8L4VRIcLBMessXevSWWlTZtDDCFVIeITMVhrKqbGxLzliDVQaUzDw2 ILVIdYYajPoQxTSQXgyPn2uapscCIF0n06LInU4CGBu3LVbp91KAxGGoAb2to/1wMG1i ltyvU9p+UNKlT37iLsESrvBGxojkzqvilQKShRX8Ib89PYR8W0hHrOlkIsIyIkL+biu7 bs46ZYMRXSkDU88uITxpRETtv5+B4v8xJ8u7CoF6PRnVlQ0WK1rzsF8EaN4Z1UEEkphk n31Q== X-Gm-Message-State: AKwxytcxetvswTTaLKTtGUBHYjnst18eSg80R2i72pHgXpiPudpJefi8 axQapXK6jrK5fRvb3Df2+bfNmg== X-Google-Smtp-Source: AH8x226LEpR/aPf747ZlVIggnGmHpfvdMBhbBmnDYn4eyrt9xa/ozXCWgbXxNLGeP4pA8XPFxG5RIQ== X-Received: by 10.80.217.10 with SMTP id t10mr71578502edj.171.1517682960160; Sat, 03 Feb 2018 10:36:00 -0800 (PST) Received: from [192.168.0.169] ([151.58.14.242]) by smtp.googlemail.com with ESMTPSA id p6sm4045139edb.62.2018.02.03.10.35.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 03 Feb 2018 10:35:59 -0800 (PST) Subject: Re: gdb 8.x - g++ 7.x compatibility To: gdb@sourceware.org, gcc@gcc.gnu.org References: <1517667601.3405.123.camel@gnu.org> From: Manfred Message-ID: Date: Sat, 03 Feb 2018 18:36: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-SW-Source: 2018-02/txt/msg00017.txt.bz2 n4659 17.4 (Type equivalence) p1.3: Two template-ids refer to the same class, function, or variable if ... their corresponding non-type template arguments of integral or enumeration type have identical values ... It looks that for non-type template arguments the template type equivalence is based on argument /value/ not /type/ (and value), so IMHO gcc is correct where it considers foo<10u> and foo<10> to be the same type, i.e. "refer to the same class" FWIW, type_info reports the same class name for both templates, which appears to be correct as per the above. I would think someone from gcc might be more specific on why both templates print 4294967286, and what debug info is actually stored by -g in this case. On 2/3/2018 6:18 PM, Roman Popov wrote: > I've just checked g++8.0.1 from trunk, and the problem is still there. And > same with Clang compiler. > > This is indeed is a serious issue for me, since my Python scripts for gdb > expect reliable dynamic type identification. However gdb is > completely powerless here. So I'm forced to stay on older compiler. > Consider this case (Results with g++ 8.0.1) > > #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; }; > }; > > int main() > { > base * fu = new foo<10u>(); > base * fi = new foo<10>(); > fu->print(); > fi->print(); > return 0; // set breakpoint here > }: > > Now check dynamic types in GDB: > > (gdb) p *fu > warning: RTTI symbol not found for class 'foo<10u>' > $1 = warning: RTTI symbol not found for class 'foo<10u>' > warning: RTTI symbol not found for class 'foo<10u>' > {_vptr.base = 0x400bd0 +16>} > > (gdb) p *fi > > (gdb) p *fi > $2 = (foo<10>) { = {_vptr.base = 0x400bb8 +16>}, *x > = 4294967286*} > > Here GDB picks wrong type! > > In RTTI type names are different. And this is correct. > > But in debuginfo both types have same name: > > foo<10> { > unsigned x; > } > foo<10> { > int x; > } > > So GDB picks the first one, which is wrong. > > -Roman > > > > > > > > > 2018-02-03 6:20 GMT-08:00 Paul Smith : > >> On Fri, 2018-02-02 at 23:54 -0500, Simon Marchi wrote: >>> Your problem is probably linked to these issues, if you want to follow >>> them: >>> >>> gcc: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81932 >>> gdb: https://sourceware.org/bugzilla/show_bug.cgi?id=22013 >>> >>> As Carl said, it's a good idea to try with the latest version of both >>> tools, but I think the issue will still be present. >>> >>> GCC changed how it outputs unsigned template parameters in the debug >>> info (from 2u to just 2), and it doesn't look like it's going to change >>> it back. So I suppose we'll have to find a way to make GDB deal with >>> it. >> >> I also tried a couple of times [1][2][3] to get a discussion started on >> the mailing lists for how to resolve this but didn't get any replies, >> and I got busy with other things. >> >> We really need to find someone who is knowlegeable on type lookup in >> GDB. That person needs to engage with the experts on the GCC side and >> hash out the right answer to this problem. In my experience, Jonathan >> Wakely on the GCC side is extremely responsive, I'm just too much of a >> tyro to be able to discuss it with him at the level needed to find a >> solution. >> >> I think it's an extremely serious issue, if GDB can't resolve some very >> common (IME) types, but so far it hasn't risen to the level of getting >> attention from those who have sufficient expertise to solve it. >> >> >> [1] https://gcc.gnu.org/ml/gcc-help/2017-08/msg00120.html >> [2] https://sourceware.org/ml/gdb/2017-08/msg00069.html >> [3] https://sourceware.org/ml/gdb/2017-09/msg00042.html >>