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
>>
next prev parent 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).