Type suffixes should be generated for non-type template parameters in Debug info.

Hello,
I’ve noticed that Clang does not emits type suffixes to debug info,
so types foo<1u> and foo<1> will be both saved to debug info as foo<1>.

Unfortunately this leaves no chance to debugger to correctly identify dynamic type. Consider example:

struct base {
virtual ~base() {}
};

template< auto IVAL>
struct foo : base {
decltype(IVAL) x = -IVAL;
};

int main()
{
base * fi = new foo<10>();
base * fu = new foo<10u>();

// BREAKPOINT HERE:
return 0;
}

Running in GDB:

(gdb) p *fi
$1 = (foo<10>) { = {_vptr$base = 0x4009d8 <vtable for foo<10>+16>}, x = 4294967286}

Wrong type!!, x == -10!!

(gdb) p *fu
warning: RTTI symbol not found for class ‘foo<10u>’
$2 = warning: RTTI symbol not found for class ‘foo<10u>’
warning: RTTI symbol not found for class ‘foo<10u>’
{_vptr$base = 0x400a58 <vtable for foo<10u>+16>}

Dynamic type not identified.

-Roman

Seems fair (though I feel like/wish, perhaps there should be an implicit type parameter in cases like this, but ah well).

I still think the idea that DWARF producers should create names that match exactly some specific demangler’s pretty printing is problematic… but in this case there’s clearly information loss that needs to be addressed.

Can you please elaborate why this is problematic? Also why not to put
mangled names into debug_info? Debugger can demangle them by itself.

Here is related GDB thread:
*https://sourceware.org/ml/gdb/2018-02/msg00021.html
<https://sourceware.org/ml/gdb/2018-02/msg00021.html>*
According to GDB developer in some cases it is impossible to reconstruct
type from template parameter tags.

It’s a rather tight coupling - there are many demanglers out there that might choose different renderings. (eg: “foo<(unsigned)0>” or “foo<0u>” or “foo<0U>” etc)

There is a way to include mangled names in DWARF (DW_AT_linkage_name) but that adds some size penalty to the debug info to include that extra information everywhere.