From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 122195 invoked by alias); 3 Feb 2018 17:18:13 -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 122177 invoked by uid 89); 3 Feb 2018 17:18:12 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=3.1 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,HTML_MESSAGE,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=no version=3.3.2 spammy=gmt08, gmt-08, GMT08, GMT-08 X-HELO: mail-wr0-f176.google.com Received: from mail-wr0-f176.google.com (HELO mail-wr0-f176.google.com) (209.85.128.176) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 03 Feb 2018 17:18:10 +0000 Received: by mail-wr0-f176.google.com with SMTP id i56so25501362wra.7 for ; Sat, 03 Feb 2018 09:18:10 -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=ZEvCd8d8BpLtKiwqK3OkOGYsCt8zISsLsYmAHPnuOtE=; b=UVjlt4qXFYnIFxq8DK81HvoQPnsXKXSO1Ktbrsug1nhnRwu9D9RlbsMrqTnKcaIwjN 3lxrLCRsGuQjT/QXM18yu2R4QMQeky2rjSeZIpDeo3+oLo5YwbDsDvuvUfOdH5d6cjiD xMIQn8x2uOKVnD3j7mbEgj+eFvmt7Zc4ZF/ZfuWpM2jCt6jL1eMJrdfI0H+dxogjHjc3 5XHK8u+xzmVO0whzPArTWWTzoH0jEqGDfR09GUuPB4tLcVWmpzKB6r53BDgAI1U+4Y+h nJ6D7NxNAZa0UzfrYw2jMo+TULNbGwHJErqlJ0ldg9sgYyDz8+EOck6DiZSHdL38gTU2 83Fg== X-Gm-Message-State: AKwxyte82CBMCodAtjQlOEYeDJsIm5oMN3JlFRs6soNX7kmNIyXPlpW9 e3UhAJAh19eYxC93GkgY6uBAWv14aiUylPQkPu4Y6g== X-Google-Smtp-Source: AH8x225Aa/EiVQ1z8Hr9ZGIKCyYQxNWr4s7eWE9C9GdzY9yIZftms5hhBlwFEQVn5GbnzpjHfLy4HGYtVTxqtmpCAU4= X-Received: by 10.223.164.148 with SMTP id g20mr38307734wrb.49.1517678288817; Sat, 03 Feb 2018 09:18:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.122.19 with HTTP; Sat, 3 Feb 2018 09:18:08 -0800 (PST) In-Reply-To: <1517667601.3405.123.camel@gnu.org> References: <1517667601.3405.123.camel@gnu.org> From: Roman Popov Date: Sat, 03 Feb 2018 17:18:00 -0000 Message-ID: Subject: Re: gdb 8.x - g++ 7.x compatibility To: psmith@gnu.org Cc: Simon Marchi , gdb@sourceware.org, gcc@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2018-02/txt/msg00014.txt.bz2 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 >