public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Manfred <mx2927@gmail.com>
To: gdb@sourceware.org, gcc@gcc.gnu.org
Subject: Re: gdb 8.x - g++ 7.x compatibility
Date: Sat, 03 Feb 2018 18:36:00 -0000	[thread overview]
Message-ID: <c6352df2-6750-2c43-1ea1-3ddacffc1d95@gmail.com> (raw)
In-Reply-To: <CAATAM3H2V53F+v4mbAO5MpBbA1O3Qady3vFv6O0Rqj=moob4CA@mail.gmail.com>

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 <iostream>
> 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 <vtable for foo<10u>+16>}
> 
> (gdb) p *fi
> 
> (gdb) p *fi
> $2 = (foo<10>) {<base> = {_vptr.base = 0x400bb8 <vtable for foo<10>+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 <psmith@gnu.org>:
> 
>> 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
>>

  reply	other threads:[~2018-02-03 18:36 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-03  3:17 Roman Popov
2018-02-03  3:57 ` carl hansen
2018-02-03  4:54 ` Simon Marchi
2018-02-03  5:02   ` Roman Popov
2018-02-03  6:43   ` Roman Popov
2018-02-03 14:20   ` Paul Smith
2018-02-03 17:18     ` Roman Popov
2018-02-03 18:36       ` Manfred [this message]
2018-02-04  5:02         ` Simon Marchi
2018-02-04 17:09           ` Manfred
2018-02-04 19:17           ` Martin Sebor
2018-02-05  5:07             ` Simon Marchi
2018-02-05 16:45               ` Martin Sebor
2018-02-05 16:59                 ` Simon Marchi
2018-02-05 17:44                   ` Roman Popov
2018-02-05 20:08                     ` Jonathan Wakely
2018-02-05 20:10                       ` Roman Popov
2018-02-05 20:12                         ` Jonathan Wakely
2018-02-05 20:17                           ` Roman Popov
2018-02-06  3:52                   ` Martin Sebor
2018-02-07  7:21                     ` Daniel Berlin
2018-02-07 13:44                       ` Simon Marchi
2018-02-07 15:07                         ` Manfred
2018-02-07 15:16                           ` Jonathan Wakely
2018-02-07 16:19                             ` Manfred
2018-02-07 16:26                         ` Michael Matz
2018-02-07 16:43                           ` Simon Marchi
2018-02-07 16:51                             ` Jonathan Wakely
2018-02-07 17:03                               ` Simon Marchi
2018-02-07 17:08                                 ` Jonathan Wakely
2018-02-07 17:20                                   ` Simon Marchi
2018-02-07 17:30                                     ` Jonathan Wakely
2018-02-07 18:28                                       ` Simon Marchi
2018-02-08 11:26                                         ` Michael Matz
2018-02-08 14:05                                           ` Paul Smith
2018-02-08 14:07                                             ` Jonathan Wakely
2018-02-07 17:31                                     ` Marc Glisse
2018-02-07 17:04                         ` Daniel Berlin
2018-02-07 17:11                           ` Daniel Berlin
2018-02-07 22:00                             ` Nathan Sidwell
2018-02-07 20:29                           ` Tom Tromey
2018-02-08 15:05               ` Richard Biener
2018-03-01 20:18                 ` Roman Popov
2018-03-01 20:26                   ` Andrew Pinski
2018-03-01 21:03                     ` Jason Merrill
2018-03-02 23:06                       ` Roman Popov
2018-03-03  4:01                         ` Roman Popov
2018-03-04  4:28                         ` Daniel Berlin
2018-02-05 11:05             ` Jonathan Wakely
2018-02-07 15:19           ` Jonathan Wakely

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c6352df2-6750-2c43-1ea1-3ddacffc1d95@gmail.com \
    --to=mx2927@gmail.com \
    --cc=gcc@gcc.gnu.org \
    --cc=gdb@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).