gdb 8.x - g++ 7.x compatibility

[Manfred]

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
>>