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

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

[Roman Popov]

Hello,
I'm trying to switch from g++ 5.4 to g++ 7.2.
GDB 8.0.1 however does not understand RTTI generated by g++7.2, so my
Python scripts for GDB are not working.

Here is a code example:

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

template< int IVAL, unsigned UVAL, unsigned long long ULLVAL>
struct derived : base {
    int x = IVAL + + UVAL + ULLVAL;
};

int main()
{
    base * o = new derived<1,2,3>{};
    return 0;
}

When compiled with g++5.4 I can read value of x in debugger.
When compiled with g++7.2   gdb reports:
warning: RTTI symbol not found for class 'derived<1, 2u, 3ull>'

Problem here is that type name saved in debug information is
*derived<1, 2, 3>*, not *derived<1, 2u, 3ull>*

Do you plan to fix this anytime soon?

Thanks,
Roman

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

[carl hansen]

On Fri, Feb 2, 2018 at 7:17 PM, Roman Popov <ripopov@gmail.com> wrote:

> Hello,
> I'm trying to switch from g++ 5.4 to g++ 7.2.
> GDB 8.0.1 however does not understand RTTI generated by g++7.2, so my
> Python scripts for GDB are not working.
>
> Here is a code example:
>
> struct base {  virtual ~base(){}  };
>
> template< int IVAL, unsigned UVAL, unsigned long long ULLVAL>
> struct derived : base {
>     int x = IVAL + + UVAL + ULLVAL;
> };
>
> int main()
> {
>     base * o = new derived<1,2,3>{};
>     return 0;
> }
>
> When compiled with g++5.4 I can read value of x in debugger.
> When compiled with g++7.2   gdb reports:
> warning: RTTI symbol not found for class 'derived<1, 2u, 3ull>'
>
> Problem here is that type name saved in debug information is
> *derived<1, 2, 3>*, not *derived<1, 2u, 3ull>*
>
> Do you plan to fix this anytime soon?
>
> Thanks,
> Roman
>
​try  gdb 8.1 and gcc 7.3 and iterate.
see if fixed, repost.​

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

[Simon Marchi]

On 2018-02-02 22:17, Roman Popov wrote:
> Hello,
> I'm trying to switch from g++ 5.4 to g++ 7.2.
> GDB 8.0.1 however does not understand RTTI generated by g++7.2, so my
> Python scripts for GDB are not working.
> 
> Here is a code example:
> 
> struct base {  virtual ~base(){}  };
> 
> template< int IVAL, unsigned UVAL, unsigned long long ULLVAL>
> struct derived : base {
>     int x = IVAL + + UVAL + ULLVAL;
> };
> 
> int main()
> {
>     base * o = new derived<1,2,3>{};
>     return 0;
> }
> 
> When compiled with g++5.4 I can read value of x in debugger.
> When compiled with g++7.2   gdb reports:
> warning: RTTI symbol not found for class 'derived<1, 2u, 3ull>'
> 
> Problem here is that type name saved in debug information is
> *derived<1, 2, 3>*, not *derived<1, 2u, 3ull>*
> 
> Do you plan to fix this anytime soon?
> 
> Thanks,
> Roman

Hi Roman,

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.

Simon

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

[Roman Popov]

Yes, problem is still there in g++7.3 / gdb 8.1.  I wonder why they decided
to emit different strings to RTTI and debug info? What is the technical
reason behind this?

-Roman

2018-02-02 20:54 GMT-08:00 Simon Marchi <simon.marchi@polymtl.ca>:

> On 2018-02-02 22:17, Roman Popov wrote:
>
>> Hello,
>> I'm trying to switch from g++ 5.4 to g++ 7.2.
>> GDB 8.0.1 however does not understand RTTI generated by g++7.2, so my
>> Python scripts for GDB are not working.
>>
>> Here is a code example:
>>
>> struct base {  virtual ~base(){}  };
>>
>> template< int IVAL, unsigned UVAL, unsigned long long ULLVAL>
>> struct derived : base {
>>     int x = IVAL + + UVAL + ULLVAL;
>> };
>>
>> int main()
>> {
>>     base * o = new derived<1,2,3>{};
>>     return 0;
>> }
>>
>> When compiled with g++5.4 I can read value of x in debugger.
>> When compiled with g++7.2   gdb reports:
>> warning: RTTI symbol not found for class 'derived<1, 2u, 3ull>'
>>
>> Problem here is that type name saved in debug information is
>> *derived<1, 2, 3>*, not *derived<1, 2u, 3ull>*
>>
>> Do you plan to fix this anytime soon?
>>
>> Thanks,
>> Roman
>>
>
> Hi Roman,
>
> 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.
>
> Simon
>

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

[Roman Popov]

2018-02-02 20:54 GMT-08:00 Simon Marchi <simon.marchi@polymtl.ca>:

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

I'm not so sure about it. In my opinion it is a gcc bug. 2u and 2 are
literals of different types. But I'm not a C++ expert.

It looks like g++ and clang treat C++ language differently in this case.
I've asked on stackoverflow:
https://stackoverflow.com/questions/48594693/auto-template-parameters-g-7-3-vs-clang-6-0-which-compiler-is-correct

If Clang is correct here, than foo<1u> and foo<1> are two different types.
And so gcc should emit correct postfixes to debuginfo.


-Roman

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

[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

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

[Roman Popov]

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
>

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

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

[Simon Marchi]

On 2018-02-03 13:35, Manfred wrote:
> 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.

I think that Roman's example clearly shows that they are not equivalent in
all cases.

Building Roman's example with g++ 7.3 results in a single instantiated type.  You
can see that both "new foo<10>()" and "new foo<10u>()" end up calling the same
constructor.  It seems like which type is instantiated depends on which template
parameter (the signed or unsigned one) you use first.  So with this:

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

the output is -10 for both, and with

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

the output is 4294967286 for both.  But it's probably a bogus behavior.  I tested
with clangd, it instantiates two different types, so you get 4294967286 for the
<10u> case and -10 for the <10> case.  I also just built gcc from master, and it
also instantiates two types, so it seems like that was fixed recently.

So let's see what debug info gcc master generates for these two instances of foo
(clang master generates the equivalent).

  <1><9257>: Abbrev Number: 66 (DW_TAG_structure_type)
     <9258>   DW_AT_name        : (indirect string, offset: 0x8455): foo<10>
     <925c>   DW_AT_byte_size   : 16
     <925d>   DW_AT_decl_file   : 1
     <925e>   DW_AT_decl_line   : 7
     <925f>   DW_AT_decl_column : 8
     <9260>   DW_AT_containing_type: <0x92fd>
     <9264>   DW_AT_sibling     : <0x92f8>
...
 <1><93be>: Abbrev Number: 66 (DW_TAG_structure_type)
    <93bf>   DW_AT_name        : (indirect string, offset: 0x8455): foo<10>
    <93c3>   DW_AT_byte_size   : 16
    <93c4>   DW_AT_decl_file   : 1
    <93c5>   DW_AT_decl_line   : 7
    <93c6>   DW_AT_decl_column : 8
    <93c7>   DW_AT_containing_type: <0x92fd>
    <93cb>   DW_AT_sibling     : <0x945f>

If there are two types with the same name, how is gdb expected to differentiate
them?

If we can't rely on the DW_AT_name anymore to differentiate templated types, then
the only alternative I see would be to make GDB ignore the template part of the
DW_AT_name value, and reconstruct it in the format it expects (with the u) from the
DW_TAG_template_value_param DIEs children of DW_TAG_structure_type (there's already
code to do that in dwarf2_compute_name).  Their types correctly point to the signed
int or unsigned int DIE, so we have the necessary information.  However, that would
mean reading many more full DIEs early on, when just building partial symbols, which
would slow done loading the symbols of pretty much any C++ program.

From what I understand from the original change that caused all this [1], removing
the suffixes was meant to make the error messages more readable for the user.
However, since foo<10>::print() and foo<10u>::print() are not the same function,
I think it would actually be more confusing if an error message talked about the
instantiation with the unsigned type, but mentioned "foo<10>::print()".  For example,
if you put a

  static_assert (std::is_signed<decltype(x)>::value);

in the print method, this is the error message from gcc:

  test.cpp: In instantiation of 'void foo<IVAL>::print() [with auto IVAL = 10]':
  test.cpp:24:1:   required from here
  test.cpp:12:22: error: static assertion failed
         static_assert (std::is_signed<decltype(x)>::value);
                        ^~~

Wouldn't the message make more sense with a u suffix?

Simon

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78165

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

[Manfred]

On 2/4/2018 6:01 AM, Simon Marchi wrote:
> On 2018-02-03 13:35, Manfred wrote:
>> 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.
> 
> I think that Roman's example clearly shows that they are not equivalent in
> all cases.
I was merely reporting the wording of the standard, which would be the 
authority to follow. I may agree that not specifying type identity may 
lead to unexpected results. Personally I would prefer the standard to 
say "identical value and type" here (and it appears from your findings 
below that quality compilers already handle it this way), but this is 
only an opinion.

> 
> Building Roman's example with g++ 7.3 results in a single instantiated type.  You
> can see that both "new foo<10>()" and "new foo<10u>()" end up calling the same
> constructor.  It seems like which type is instantiated depends on which template
> parameter (the signed or unsigned one) you use first.  So with this:
> 
>       base * fi = new foo<10>();
>       base * fu = new foo<10u>();
> 
> the output is -10 for both, and with
> 
>       base * fu = new foo<10u>();
>       base * fi = new foo<10>();
> 
> the output is 4294967286 for both.  But it's probably a bogus behavior.
Indeed.

   I tested
> with clangd, it instantiates two different types, so you get 4294967286 for the
> <10u> case and -10 for the <10> case.  I also just built gcc from master, and it
> also instantiates two types, so it seems like that was fixed recently.
> 
> So let's see what debug info gcc master generates for these two instances of foo
> (clang master generates the equivalent).
> 
>    <1><9257>: Abbrev Number: 66 (DW_TAG_structure_type)
>       <9258>   DW_AT_name        : (indirect string, offset: 0x8455): foo<10>
>       <925c>   DW_AT_byte_size   : 16
>       <925d>   DW_AT_decl_file   : 1
>       <925e>   DW_AT_decl_line   : 7
>       <925f>   DW_AT_decl_column : 8
>       <9260>   DW_AT_containing_type: <0x92fd>
>       <9264>   DW_AT_sibling     : <0x92f8>
> ...
>   <1><93be>: Abbrev Number: 66 (DW_TAG_structure_type)
>      <93bf>   DW_AT_name        : (indirect string, offset: 0x8455): foo<10>
>      <93c3>   DW_AT_byte_size   : 16
>      <93c4>   DW_AT_decl_file   : 1
>      <93c5>   DW_AT_decl_line   : 7
>      <93c6>   DW_AT_decl_column : 8
>      <93c7>   DW_AT_containing_type: <0x92fd>
>      <93cb>   DW_AT_sibling     : <0x945f>
> 
> If there are two types with the same name, how is gdb expected to differentiate
> them?
> 
> If we can't rely on the DW_AT_name anymore to differentiate templated types, then
> the only alternative I see would be to make GDB ignore the template part of the
> DW_AT_name value, and reconstruct it in the format it expects (with the u) from the
> DW_TAG_template_value_param DIEs children of DW_TAG_structure_type (there's already
> code to do that in dwarf2_compute_name).  Their types correctly point to the signed
> int or unsigned int DIE, so we have the necessary information.  However, that would
> mean reading many more full DIEs early on, when just building partial symbols, which
> would slow done loading the symbols of pretty much any C++ program.
> 
>  From what I understand from the original change that caused all this [1], removing
> the suffixes was meant to make the error messages more readable for the user.
> However, since foo<10>::print() and foo<10u>::print() are not the same function,
> I think it would actually be more confusing if an error message talked about the
> instantiation with the unsigned type, but mentioned "foo<10>::print()".  For example,
> if you put a
> 
>    static_assert (std::is_signed<decltype(x)>::value);
> 
> in the print method, this is the error message from gcc:
> 
>    test.cpp: In instantiation of 'void foo<IVAL>::print() [with auto IVAL = 10]':
>    test.cpp:24:1:   required from here
>    test.cpp:12:22: error: static assertion failed
>           static_assert (std::is_signed<decltype(x)>::value);
>                          ^~~
> 
> Wouldn't the message make more sense with a u suffix?
Probably so.

> 
> Simon
> 
> [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78165
> 

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

[Martin Sebor]

On 02/03/2018 10:01 PM, Simon Marchi wrote:
> On 2018-02-03 13:35, Manfred wrote:
>> 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.
>
> I think that Roman's example clearly shows that they are not equivalent in
> all cases.
>
> Building Roman's example with g++ 7.3 results in a single instantiated type.  You
> can see that both "new foo<10>()" and "new foo<10u>()" end up calling the same
> constructor.  It seems like which type is instantiated depends on which template
> parameter (the signed or unsigned one) you use first.  So with this:
>
>      base * fi = new foo<10>();
>      base * fu = new foo<10u>();
>
> the output is -10 for both, and with
>
>      base * fu = new foo<10u>();
>      base * fi = new foo<10>();
>
> the output is 4294967286 for both.  But it's probably a bogus behavior.  I tested
> with clangd, it instantiates two different types, so you get 4294967286 for the
> <10u> case and -10 for the <10> case.  I also just built gcc from master, and it
> also instantiates two types, so it seems like that was fixed recently.
>
> So let's see what debug info gcc master generates for these two instances of foo
> (clang master generates the equivalent).
>
>   <1><9257>: Abbrev Number: 66 (DW_TAG_structure_type)
>      <9258>   DW_AT_name        : (indirect string, offset: 0x8455): foo<10>
>      <925c>   DW_AT_byte_size   : 16
>      <925d>   DW_AT_decl_file   : 1
>      <925e>   DW_AT_decl_line   : 7
>      <925f>   DW_AT_decl_column : 8
>      <9260>   DW_AT_containing_type: <0x92fd>
>      <9264>   DW_AT_sibling     : <0x92f8>
> ...
>  <1><93be>: Abbrev Number: 66 (DW_TAG_structure_type)
>     <93bf>   DW_AT_name        : (indirect string, offset: 0x8455): foo<10>
>     <93c3>   DW_AT_byte_size   : 16
>     <93c4>   DW_AT_decl_file   : 1
>     <93c5>   DW_AT_decl_line   : 7
>     <93c6>   DW_AT_decl_column : 8
>     <93c7>   DW_AT_containing_type: <0x92fd>
>     <93cb>   DW_AT_sibling     : <0x945f>
>
> If there are two types with the same name, how is gdb expected to differentiate
> them?
>
> If we can't rely on the DW_AT_name anymore to differentiate templated types, then
> the only alternative I see would be to make GDB ignore the template part of the
> DW_AT_name value, and reconstruct it in the format it expects (with the u) from the
> DW_TAG_template_value_param DIEs children of DW_TAG_structure_type (there's already
> code to do that in dwarf2_compute_name).  Their types correctly point to the signed
> int or unsigned int DIE, so we have the necessary information.  However, that would
> mean reading many more full DIEs early on, when just building partial symbols, which
> would slow done loading the symbols of pretty much any C++ program.
>
> From what I understand from the original change that caused all this [1], removing
> the suffixes was meant to make the error messages more readable for the user.

Readability was a factor but it wasn't the main motivation for
the change.

Printing the suffix is unhelpful because it leads to unnecessary
differences in diagnostics (even in non-template contexts).  For
templates with non-type template parameters there is no difference
between, say A<1>, A<1U>, A<(unsigned) 1>, or even A<Green> when
Green is an enumerator that evaluates to 1, so including the suffix
serves no useful purpose.  In the GCC test suite, it would tend to
cause failures due to differences between the underlying type of
common typedefs like size_t and ptrdiff_t.  Avoiding these
unnecessary differences was the main motivation for the change.
Not necessarily just in the GCC test suite but in all setups that
process GCC messages.

> However, since foo<10>::print() and foo<10u>::print() are not the same function,
> I think it would actually be more confusing if an error message talked about the
> instantiation with the unsigned type, but mentioned "foo<10>::print()".  For example,
> if you put a
>
>   static_assert (std::is_signed<decltype(x)>::value);
>
> in the print method, this is the error message from gcc:
>
>   test.cpp: In instantiation of 'void foo<IVAL>::print() [with auto IVAL = 10]':
>   test.cpp:24:1:   required from here
>   test.cpp:12:22: error: static assertion failed
>          static_assert (std::is_signed<decltype(x)>::value);
>                         ^~~
>
> Wouldn't the message make more sense with a u suffix?

I think this message would be the most meaningful if the "auto"
part were replaced with the deduced type.  With that, the suffix
of the constant isn't important, just as in other contexts.

I didn't consider the use of auto as a template parameter but
I don't think it changes anything.  There, just like in other
contexts, what's important is the deduced types and the values
of constants, not the minute details of how they are spelled.

That said, it wasn't my intention to make things difficult for
the debugger.  But changing GCC back to include the suffix,
even just in the debug info, isn't a solution.  There are other
compilers besides GCC that don't emit the suffixes, and there
even are some that prepend a cast to the number, so if GDB is
to be usable with all these kinds of producers it needs to be
able to handle all of these forms.

Martin

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

[Simon Marchi]

Hi Martin,

Thanks for the reply.

On 2018-02-04 02:17 PM, Martin Sebor wrote:
> Printing the suffix is unhelpful because it leads to unnecessary
> differences in diagnostics (even in non-template contexts).  For
> templates with non-type template parameters there is no difference
> between, say A<1>, A<1U>, A<(unsigned) 1>, or even A<Green> when
> Green is an enumerator that evaluates to 1, so including the suffix
> serves no useful purpose.

This is the part I don't understand.  In Roman's example, spelling
foo<10> and foo<10u> resulted in two different instantiations of the
template, with different code.  So that means it can make a difference,
can't it?

> In the GCC test suite, it would tend to
> cause failures due to differences between the underlying type of
> common typedefs like size_t and ptrdiff_t.  Avoiding these
> unnecessary differences was the main motivation for the change.
> Not necessarily just in the GCC test suite but in all setups that
> process GCC messages.

Ok, I understand.

> I didn't consider the use of auto as a template parameter but
> I don't think it changes anything.  There, just like in other
> contexts, what's important is the deduced types and the values
> of constants, not the minute details of how they are spelled.

Well, it seems like using decltype on a template constant value is
a way to make the type of constants important, in addition to their
value.  I know the standard seems to say otherwise (what Manfred
quoted), but the reality seems different.  I'm not a language expert
so I can't tell if this is a deficiency in the language or not.

> That said, it wasn't my intention to make things difficult for
> the debugger.

I hope so :).

> But changing GCC back to include the suffix,
> even just in the debug info, isn't a solution.  There are other
> compilers besides GCC that don't emit the suffixes, and there
> even are some that prepend a cast to the number, so if GDB is
> to be usable with all these kinds of producers it needs to be
> able to handle all of these forms.

As I said earlier, there are probably ways to make GDB cope with it.
The only solution I saw (I'd like to hear about other ones) was to make
GDB ignore the template part in DW_AT_name and re-build it from the
DW_TAG_template_* DIEs in the format it expects.  It can already do
that somewhat, because, as you said, some compilers don't emit
the template part in DW_AT_name.

Doing so would cause major slowdowns in symbol reading, I've tried it
for the sake of experimentation/discussion.  I have a patch available
on the "users/simark/template-suffix" branch in the binutils-gdb
repo [1].  It works for Roman's example, but running the GDB testsuite
shows that, of course, the devil is in the details.

Consider something like this:

  template <int *P>
  struct foo { virtual ~foo() {} };

  int n;

  int main ()
  {
    foo<&n> f;
  }


The demangled name that GDB will be looking up is "foo<&n>".  The
debug info about the template parameter only contains the resulting
address of n (the value of &n):

 <2><bf>: Abbrev Number: 11 (DW_TAG_template_value_param)
    <c0>   DW_AT_name        : P
    <c2>   DW_AT_type        : <0x1ac>
    <c6>   DW_AT_location    : 10 byte block: 3 34 10 60 0 0 0 0 0 9f   (DW_OP_addr: 601034; DW_OP_stack_value)

I don't see how GDB could reconstruct the "&n" in the template, so
that's where my idea falls short.

Simon

[1] https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=shortlog;h=refs/heads/users/simark/template-suffix

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

[Stephan Bergmann]

On 05.02.2018 06:06, Simon Marchi wrote:
> On 2018-02-04 02:17 PM, Martin Sebor wrote:
>> Printing the suffix is unhelpful because it leads to unnecessary
>> differences in diagnostics (even in non-template contexts).  For
>> templates with non-type template parameters there is no difference
>> between, say A<1>, A<1U>, A<(unsigned) 1>, or even A<Green> when
>> Green is an enumerator that evaluates to 1, so including the suffix
>> serves no useful purpose.
> 
> This is the part I don't understand.  In Roman's example, spelling
> foo<10> and foo<10u> resulted in two different instantiations of the
> template, with different code.  So that means it can make a difference,
> can't it?

Yes, for non-type template parameters whose type contains a placeholder 
type (i.e., "auto IVAL" in the earlier example), which is a new feature 
of C++17.

My understanding is that printing the suffix would be essential in such 
cases.

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

[Jonathan Wakely]

On 5 February 2018 at 09:16, Stephan Bergmann wrote:
> On 05.02.2018 06:06, Simon Marchi wrote:
>>
>> On 2018-02-04 02:17 PM, Martin Sebor wrote:
>>>
>>> Printing the suffix is unhelpful because it leads to unnecessary
>>> differences in diagnostics (even in non-template contexts).  For
>>> templates with non-type template parameters there is no difference
>>> between, say A<1>, A<1U>, A<(unsigned) 1>, or even A<Green> when
>>> Green is an enumerator that evaluates to 1, so including the suffix
>>> serves no useful purpose.
>>
>>
>> This is the part I don't understand.  In Roman's example, spelling
>> foo<10> and foo<10u> resulted in two different instantiations of the
>> template, with different code.  So that means it can make a difference,
>> can't it?
>
>
> Yes, for non-type template parameters whose type contains a placeholder type
> (i.e., "auto IVAL" in the earlier example), which is a new feature of C++17.

Right, for C++14 saying foo<2> is entirely unambiguous because the
type of the template parameter is fixed. For C++17 a template declared
as "template<auto> class foo" can be instantiated with different
types, so foo<2> and foo<2u> don't refer to the same specialiation.

> My understanding is that printing the suffix would be essential in such
> cases.

Not sufficient, it doesn't help distinguish foo<(short)2>, foo<(int)2>
or foo<(signed char)2> because there is no suffix for signed/unsigned
short or signed/unsigned char.

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

[Martin Sebor]

On 02/04/2018 10:06 PM, Simon Marchi wrote:
> Hi Martin,
>
> Thanks for the reply.
>
> On 2018-02-04 02:17 PM, Martin Sebor wrote:
>> Printing the suffix is unhelpful because it leads to unnecessary
>> differences in diagnostics (even in non-template contexts).  For
>> templates with non-type template parameters there is no difference
>> between, say A<1>, A<1U>, A<(unsigned) 1>, or even A<Green> when
>> Green is an enumerator that evaluates to 1, so including the suffix
>> serves no useful purpose.
>
> This is the part I don't understand.  In Roman's example, spelling
> foo<10> and foo<10u> resulted in two different instantiations of the
> template, with different code.  So that means it can make a difference,
> can't it?

Yes, with auto, the type of the constant does determine the type
of the specialization of the template in the source code.

In non-type template arguments, and more to the point I was making,
in diagnostics, the suffix shouldn't or doesn't need to be what
distinguishes the type of the template, even with auto.  The part
"with auto IVAL = 10" in the message

   'void foo<IVAL>::print() [with auto IVAL = 10]':

would be far clearer if auto were replaced by the deduced type,
say along these lines:

   'void foo<IVAL>::print() [with int IVAL = 10]':

rather than relying on the suffix alone to distinguish between
different specializations of the template.  That seems far too
subtle to me.  But I think the diagnostic format is (or should
be) independent of the debug info.

>> In the GCC test suite, it would tend to
>> cause failures due to differences between the underlying type of
>> common typedefs like size_t and ptrdiff_t.  Avoiding these
>> unnecessary differences was the main motivation for the change.
>> Not necessarily just in the GCC test suite but in all setups that
>> process GCC messages.
>
> Ok, I understand.
>
>> I didn't consider the use of auto as a template parameter but
>> I don't think it changes anything.  There, just like in other
>> contexts, what's important is the deduced types and the values
>> of constants, not the minute details of how they are spelled.
>
> Well, it seems like using decltype on a template constant value is
> a way to make the type of constants important, in addition to their
> value.  I know the standard seems to say otherwise (what Manfred
> quoted), but the reality seems different.  I'm not a language expert
> so I can't tell if this is a deficiency in the language or not.
>
>> That said, it wasn't my intention to make things difficult for
>> the debugger.
>
> I hope so :).
>
>> But changing GCC back to include the suffix,
>> even just in the debug info, isn't a solution.  There are other
>> compilers besides GCC that don't emit the suffixes, and there
>> even are some that prepend a cast to the number, so if GDB is
>> to be usable with all these kinds of producers it needs to be
>> able to handle all of these forms.
>
> As I said earlier, there are probably ways to make GDB cope with it.
> The only solution I saw (I'd like to hear about other ones) was to make
> GDB ignore the template part in DW_AT_name and re-build it from the
> DW_TAG_template_* DIEs in the format it expects.  It can already do
> that somewhat, because, as you said, some compilers don't emit
> the template part in DW_AT_name.
>
> Doing so would cause major slowdowns in symbol reading, I've tried it
> for the sake of experimentation/discussion.  I have a patch available
> on the "users/simark/template-suffix" branch in the binutils-gdb
> repo [1].  It works for Roman's example, but running the GDB testsuite
> shows that, of course, the devil is in the details.
>
> Consider something like this:
>
>   template <int *P>
>   struct foo { virtual ~foo() {} };
>
>   int n;
>
>   int main ()
>   {
>     foo<&n> f;
>   }
>
>
> The demangled name that GDB will be looking up is "foo<&n>".  The
> debug info about the template parameter only contains the resulting
> address of n (the value of &n):
>
>  <2><bf>: Abbrev Number: 11 (DW_TAG_template_value_param)
>     <c0>   DW_AT_name        : P
>     <c2>   DW_AT_type        : <0x1ac>
>     <c6>   DW_AT_location    : 10 byte block: 3 34 10 60 0 0 0 0 0 9f   (DW_OP_addr: 601034; DW_OP_stack_value)
>
> I don't see how GDB could reconstruct the "&n" in the template, so
> that's where my idea falls short.

I'm afraid I know too little about the internals of GDB to
fully appreciate the importance of this problem or have
an idea how it could be handled.

With respect to the suffix, I keep coming back to the reality
that even if GCC were to change to emit a format that GDB can
interpret easily and efficiently, there still are other
compilers that emit a different format.  So the conclusion
that a general solution that handles more than just one format
(at least for non-type template arguments without auto) seems
unescapable.

For auto, since it's new, a viable alternative might be to
standardize the debug info format so that eventually all
producers will converge on it. But even that approach won't
help users of existing compilers.

Martin

>
> Simon
>
> [1] https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=shortlog;h=refs/heads/users/simark/template-suffix
>

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

[Simon Marchi]

On 2018-02-05 11:45, Martin Sebor wrote:
> Yes, with auto, the type of the constant does determine the type
> of the specialization of the template in the source code.
> 
> In non-type template arguments, and more to the point I was making,
> in diagnostics, the suffix shouldn't or doesn't need to be what
> distinguishes the type of the template, even with auto.  The part
> "with auto IVAL = 10" in the message
> 
>   'void foo<IVAL>::print() [with auto IVAL = 10]':
> 
> would be far clearer if auto were replaced by the deduced type,
> say along these lines:
> 
>   'void foo<IVAL>::print() [with int IVAL = 10]':
> 
> rather than relying on the suffix alone to distinguish between
> different specializations of the template.  That seems far too
> subtle to me.  But I think the diagnostic format is (or should
> be) independent of the debug info.

That makes sense.

> With respect to the suffix, I keep coming back to the reality
> that even if GCC were to change to emit a format that GDB can
> interpret easily and efficiently, there still are other
> compilers that emit a different format.  So the conclusion
> that a general solution that handles more than just one format
> (at least for non-type template arguments without auto) seems
> unescapable.

If there are other compilers we wanted to support for which we can't 
trust the template format, we could always ignore the template part of 
DW_AT_name specifically for them.  But since g++ and gdb are part of the 
same project and are expected to work well and efficiently together, I 
would have hoped that we could agree on a format so that gdb would not 
have to do the extra work when parsing a g++-generated file 
(consequently the same format that libiberty's demangler produces).

Given the problem I illustrated in my previous mail, I don't have a 
general solution to the problem to propose.

Simon

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

[Roman Popov]

Interestingly RTTI name also gives no guarantees:
http://en.cppreference.com/w/cpp/types/type_info/name

<< Returns an implementation defined null-terminated character string
containing the name of the type. No guarantees are given; in particular,
the returned string can be identical for several types and change between
invocations of the same program. >>

It probably makes sense to look how g++ implements
std::type_info::operator== . Probably there are some hints that GDB
algorithm can utilize.
Operator std::type_info::operator== must return true for equivalent types.


2018-02-05 8:59 GMT-08:00 Simon Marchi <simon.marchi@polymtl.ca>:

> On 2018-02-05 11:45, Martin Sebor wrote:
>
>> Yes, with auto, the type of the constant does determine the type
>> of the specialization of the template in the source code.
>>
>> In non-type template arguments, and more to the point I was making,
>> in diagnostics, the suffix shouldn't or doesn't need to be what
>> distinguishes the type of the template, even with auto.  The part
>> "with auto IVAL = 10" in the message
>>
>>   'void foo<IVAL>::print() [with auto IVAL = 10]':
>>
>> would be far clearer if auto were replaced by the deduced type,
>> say along these lines:
>>
>>   'void foo<IVAL>::print() [with int IVAL = 10]':
>>
>> rather than relying on the suffix alone to distinguish between
>> different specializations of the template.  That seems far too
>> subtle to me.  But I think the diagnostic format is (or should
>> be) independent of the debug info.
>>
>
> That makes sense.
>
> With respect to the suffix, I keep coming back to the reality
>> that even if GCC were to change to emit a format that GDB can
>> interpret easily and efficiently, there still are other
>> compilers that emit a different format.  So the conclusion
>> that a general solution that handles more than just one format
>> (at least for non-type template arguments without auto) seems
>> unescapable.
>>
>
> If there are other compilers we wanted to support for which we can't trust
> the template format, we could always ignore the template part of DW_AT_name
> specifically for them.  But since g++ and gdb are part of the same project
> and are expected to work well and efficiently together, I would have hoped
> that we could agree on a format so that gdb would not have to do the extra
> work when parsing a g++-generated file (consequently the same format that
> libiberty's demangler produces).
>
> Given the problem I illustrated in my previous mail, I don't have a
> general solution to the problem to propose.
>
> Simon
>

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

[Jonathan Wakely]

On 5 February 2018 at 17:44, Roman Popov wrote:
> Interestingly RTTI name also gives no guarantees:
> http://en.cppreference.com/w/cpp/types/type_info/name
>
> << Returns an implementation defined null-terminated character string
> containing the name of the type. No guarantees are given; in particular,
> the returned string can be identical for several types and change between
> invocations of the same program. >>
>
> It probably makes sense to look how g++ implements
> std::type_info::operator== . Probably there are some hints that GDB
> algorithm can utilize.
> Operator std::type_info::operator== must return true for equivalent types.

It's the mangled name.

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

[Roman Popov]

Do you mean that g++ guarantees uniqueness of mangled names for types? And
uses name compare for operator==  ?

2018-02-05 12:08 GMT-08:00 Jonathan Wakely <jwakely.gcc@gmail.com>:

> On 5 February 2018 at 17:44, Roman Popov wrote:
> > Interestingly RTTI name also gives no guarantees:
> > http://en.cppreference.com/w/cpp/types/type_info/name
> >
> > << Returns an implementation defined null-terminated character string
> > containing the name of the type. No guarantees are given; in particular,
> > the returned string can be identical for several types and change between
> > invocations of the same program. >>
> >
> > It probably makes sense to look how g++ implements
> > std::type_info::operator== . Probably there are some hints that GDB
> > algorithm can utilize.
> > Operator std::type_info::operator== must return true for equivalent
> types.
>
> It's the mangled name.
>

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

[Jonathan Wakely]

On 5 February 2018 at 20:10, Roman Popov wrote:
> Do you mean that g++ guarantees uniqueness of mangled names for types? And

Of course. The mangled name is determined by the ABI and must be
stable, predictable and unique, so that linking works.

> uses name compare for operator==  ?

Yes.

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

[Roman Popov]

Well, if ABI has specification for type naming, why not to put this name to
debug_info so debugger can use it?

In this case argument that "each producer has its own naming conventions"
no longer works.  Any producer for given ABI must use ABI-specified names.



2018-02-05 12:12 GMT-08:00 Jonathan Wakely <jwakely.gcc@gmail.com>:

> On 5 February 2018 at 20:10, Roman Popov wrote:
> > Do you mean that g++ guarantees uniqueness of mangled names for types?
> And
>
> Of course. The mangled name is determined by the ABI and must be
> stable, predictable and unique, so that linking works.
>
> > uses name compare for operator==  ?
>
> Yes.
>

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

[Martin Sebor]

On 02/05/2018 09:59 AM, Simon Marchi wrote:
> On 2018-02-05 11:45, Martin Sebor wrote:
>> Yes, with auto, the type of the constant does determine the type
>> of the specialization of the template in the source code.
>>
>> In non-type template arguments, and more to the point I was making,
>> in diagnostics, the suffix shouldn't or doesn't need to be what
>> distinguishes the type of the template, even with auto.  The part
>> "with auto IVAL = 10" in the message
>>
>>   'void foo<IVAL>::print() [with auto IVAL = 10]':
>>
>> would be far clearer if auto were replaced by the deduced type,
>> say along these lines:
>>
>>   'void foo<IVAL>::print() [with int IVAL = 10]':
>>
>> rather than relying on the suffix alone to distinguish between
>> different specializations of the template.  That seems far too
>> subtle to me.  But I think the diagnostic format is (or should
>> be) independent of the debug info.
>
> That makes sense.
>
>> With respect to the suffix, I keep coming back to the reality
>> that even if GCC were to change to emit a format that GDB can
>> interpret easily and efficiently, there still are other
>> compilers that emit a different format.  So the conclusion
>> that a general solution that handles more than just one format
>> (at least for non-type template arguments without auto) seems
>> unescapable.
>
> If there are other compilers we wanted to support for which we can't
> trust the template format, we could always ignore the template part of
> DW_AT_name specifically for them.  But since g++ and gdb are part of the
> same project and are expected to work well and efficiently together, I
> would have hoped that we could agree on a format so that gdb would not
> have to do the extra work when parsing a g++-generated file
> (consequently the same format that libiberty's demangler produces).
>
> Given the problem I illustrated in my previous mail, I don't have a
> general solution to the problem to propose.

Okay, let me talk to Jason to see what he thinks.  I'm open
to restoring the suffix for the debug info as long as it doesn't
adversely affect the diagnostics.  I agree that if GCC can help
make GDB more efficient it's worth putting effort into.  (I do
still think that GDB should work with other providers besides
GCC, even if perhaps not necessarily as efficiently.)

Martin

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

[Daniel Berlin]

As the person who, eons ago, wrote a bunch of the the GDB code for this C++
ABI support, and as someone who helped with DWARF support in both GDB and
GCC, let me try to propose a useful path forward (in the hopes that someone
will say "that's horrible, do it this <clearly better way> instead")

Here are the constraints i believe we are working with.

1. GDB should work with multiple DWARF producers and multiple C++ compilers
implementing the C++ ABI
2. There is no canonical demangled format for the C++ ABI
3. There is no canoncial target demangler you can say everyone should use
(and even if there was, you don't want to avoid debugging working because
someone chose not to)
4. You don't want to slow down GDB if you can avoid it
5. Despite them all implementation the same ABI, it's still possible to
distinguish the producers by the producer/compiler in the dwarf info.

Given all that:

GDB has ABI hooks that tell it what to do for various C++ ABIs. This is how
it knows to call the right demangler for gcc v3's abi vs gcc v2's abi. and
handle various differences between them.

See gdb/cp-abi.h

The IMHO, obvious thing to do here is: Handle the resulting demangler
differences with 1 or more new C++ ABI hooks.
Or, introduce C++ debuginfo producer hooks that the C++ ABI hooks use if
folks want it to be separate.

Once the producer is detected, fill in the hooks with a set of functions
that does the right thing.

I imagine this would also clean up a bundle of hacks in various parts of
gdb trying to handle these differences anyway (which is where a lot of the
multiple symbol lookups/etc that are often slow come from.
If we just detected and said "this is gcc 6, it behaves like this", we
wouldn't need to do that)

In case you are worried, you will discover this is how a bunch of stuff is
done and already contains a ball of hacks.

Using hooks would be, IMHO, a significant improvement.



On Mon, Feb 5, 2018 at 7:52 PM, Martin Sebor <msebor@gmail.com> wrote:

> On 02/05/2018 09:59 AM, Simon Marchi wrote:
>
>> On 2018-02-05 11:45, Martin Sebor wrote:
>>
>>> Yes, with auto, the type of the constant does determine the type
>>> of the specialization of the template in the source code.
>>>
>>> In non-type template arguments, and more to the point I was making,
>>> in diagnostics, the suffix shouldn't or doesn't need to be what
>>> distinguishes the type of the template, even with auto.  The part
>>> "with auto IVAL = 10" in the message
>>>
>>>   'void foo<IVAL>::print() [with auto IVAL = 10]':
>>>
>>> would be far clearer if auto were replaced by the deduced type,
>>> say along these lines:
>>>
>>>   'void foo<IVAL>::print() [with int IVAL = 10]':
>>>
>>> rather than relying on the suffix alone to distinguish between
>>> different specializations of the template.  That seems far too
>>> subtle to me.  But I think the diagnostic format is (or should
>>> be) independent of the debug info.
>>>
>>
>> That makes sense.
>>
>> With respect to the suffix, I keep coming back to the reality
>>> that even if GCC were to change to emit a format that GDB can
>>> interpret easily and efficiently, there still are other
>>> compilers that emit a different format.  So the conclusion
>>> that a general solution that handles more than just one format
>>> (at least for non-type template arguments without auto) seems
>>> unescapable.
>>>
>>
>> If there are other compilers we wanted to support for which we can't
>> trust the template format, we could always ignore the template part of
>> DW_AT_name specifically for them.  But since g++ and gdb are part of the
>> same project and are expected to work well and efficiently together, I
>> would have hoped that we could agree on a format so that gdb would not
>> have to do the extra work when parsing a g++-generated file
>> (consequently the same format that libiberty's demangler produces).
>>
>> Given the problem I illustrated in my previous mail, I don't have a
>> general solution to the problem to propose.
>>
>
> Okay, let me talk to Jason to see what he thinks.  I'm open
> to restoring the suffix for the debug info as long as it doesn't
> adversely affect the diagnostics.  I agree that if GCC can help
> make GDB more efficient it's worth putting effort into.  (I do
> still think that GDB should work with other providers besides
> GCC, even if perhaps not necessarily as efficiently.)
>
> Martin
>

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

[Simon Marchi]

On 2018-02-07 02:21, Daniel Berlin wrote:
> As the person who, eons ago, wrote a bunch of the the GDB code for this 
> C++
> ABI support, and as someone who helped with DWARF support in both GDB 
> and
> GCC, let me try to propose a useful path forward (in the hopes that 
> someone
> will say "that's horrible, do it this <clearly better way> instead")
> 
> Here are the constraints i believe we are working with.
> 
> 1. GDB should work with multiple DWARF producers and multiple C++ 
> compilers
> implementing the C++ ABI
> 2. There is no canonical demangled format for the C++ ABI
> 3. There is no canoncial target demangler you can say everyone should 
> use
> (and even if there was, you don't want to avoid debugging working 
> because
> someone chose not to)
> 4. You don't want to slow down GDB if you can avoid it
> 5. Despite them all implementation the same ABI, it's still possible to
> distinguish the producers by the producer/compiler in the dwarf info.
> 
> Given all that:
> 
> GDB has ABI hooks that tell it what to do for various C++ ABIs. This is 
> how
> it knows to call the right demangler for gcc v3's abi vs gcc v2's abi. 
> and
> handle various differences between them.
> 
> See gdb/cp-abi.h
> 
> The IMHO, obvious thing to do here is: Handle the resulting demangler
> differences with 1 or more new C++ ABI hooks.
> Or, introduce C++ debuginfo producer hooks that the C++ ABI hooks use 
> if
> folks want it to be separate.
> 
> Once the producer is detected, fill in the hooks with a set of 
> functions
> that does the right thing.
> 
> I imagine this would also clean up a bundle of hacks in various parts 
> of
> gdb trying to handle these differences anyway (which is where a lot of 
> the
> multiple symbol lookups/etc that are often slow come from.
> If we just detected and said "this is gcc 6, it behaves like this", we
> wouldn't need to do that)
> 
> In case you are worried, you will discover this is how a bunch of stuff 
> is
> done and already contains a ball of hacks.
> 
> Using hooks would be, IMHO, a significant improvement.

Hi Daniel,

Thanks for chiming in.

This addresses the issue of how to do good software design in GDB to 
support different producers cleanly, but I think we have some issues 
even before that, like how to support g++ 7.3 and up.  I'll try to 
summarize the issue quickly.  It's now possible to end up with two 
templated classes with the same name that differ only by the signedness 
of their non-type template parameter.  One is Foo<int N> and the other 
is Foo<unsigned int N> (the 10 is unsigned).  Until 7.3, g++ would 
generate names like Foo<10> for the former and names like Foo<10u> for 
the later (in the DW_AT_name attribute of the classes' DIEs).  Since 
7.3, it produces Foo<10> for both.

When GDB wants to know the run time type of an object, it fetches the 
pointer to its vtable, does a symbol lookup to get the linkage name and 
demangles it, which gives a string like "vtable for Foo<10>" or "vtable 
for Foo<10u>".  It strips the "vtable for " and uses the remainder to do 
a type lookup.  Since g++ 7.3, you can see that doing a type lookup for 
Foo<10> may find the wrong type, and doing a lookup for Foo<10u> won't 
find anything.

So the problem here is how to uniquely identify those two classes when 
we are doing this run-time type finding operation (and probably in other 
cases too).

Simon

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

[Manfred]

On 02/07/2018 02:44 PM, Simon Marchi wrote:
> On 2018-02-07 02:21, Daniel Berlin wrote:
>> As the person who, eons ago, wrote a bunch of the the GDB code for 
>> this C++
>> ABI support, and as someone who helped with DWARF support in both GDB and
>> GCC, let me try to propose a useful path forward (in the hopes that 
>> someone
>> will say "that's horrible, do it this <clearly better way> instead")
>>
>> Here are the constraints i believe we are working with.
>>
>> 1. GDB should work with multiple DWARF producers and multiple C++ 
>> compilers
>> implementing the C++ ABI
>> 2. There is no canonical demangled format for the C++ ABI
>> 3. There is no canoncial target demangler you can say everyone should use
>> (and even if there was, you don't want to avoid debugging working because
>> someone chose not to)
>> 4. You don't want to slow down GDB if you can avoid it
>> 5. Despite them all implementation the same ABI, it's still possible to
>> distinguish the producers by the producer/compiler in the dwarf info.
>>
>> Given all that:
>>
>> GDB has ABI hooks that tell it what to do for various C++ ABIs. This 
>> is how
>> it knows to call the right demangler for gcc v3's abi vs gcc v2's abi. 
>> and
>> handle various differences between them.
>>
>> See gdb/cp-abi.h
>>
>> The IMHO, obvious thing to do here is: Handle the resulting demangler
>> differences with 1 or more new C++ ABI hooks.
>> Or, introduce C++ debuginfo producer hooks that the C++ ABI hooks use if
>> folks want it to be separate.
>>
>> Once the producer is detected, fill in the hooks with a set of functions
>> that does the right thing.
>>
>> I imagine this would also clean up a bundle of hacks in various parts of
>> gdb trying to handle these differences anyway (which is where a lot of 
>> the
>> multiple symbol lookups/etc that are often slow come from.
>> If we just detected and said "this is gcc 6, it behaves like this", we
>> wouldn't need to do that)
>>
>> In case you are worried, you will discover this is how a bunch of 
>> stuff is
>> done and already contains a ball of hacks.
>>
>> Using hooks would be, IMHO, a significant improvement.
> 
> Hi Daniel,
> 
> Thanks for chiming in.
> 
> This addresses the issue of how to do good software design in GDB to 
> support different producers cleanly, but I think we have some issues 
> even before that, like how to support g++ 7.3 and up.  I'll try to 
> summarize the issue quickly.  It's now possible to end up with two 
> templated classes with the same name that differ only by the signedness 
> of their non-type template parameter.  One is Foo<int N> and the other 
> is Foo<unsigned int N> (the 10 is unsigned).  Until 7.3, g++ would 
> generate names like Foo<10> for the former and names like Foo<10u> for 
> the later (in the DW_AT_name attribute of the classes' DIEs).  Since 
> 7.3, it produces Foo<10> for both.
> 
> When GDB wants to know the run time type of an object, it fetches the 
> pointer to its vtable, does a symbol lookup to get the linkage name and 
> demangles it, which gives a string like "vtable for Foo<10>" or "vtable 
> for Foo<10u>".  It strips the "vtable for " and uses the remainder to do 
> a type lookup.  Since g++ 7.3, you can see that doing a type lookup for 
> Foo<10> may find the wrong type, and doing a lookup for Foo<10u> won't 
> find anything.
> 
> So the problem here is how to uniquely identify those two classes when 
> we are doing this run-time type finding operation (and probably in other 
> cases too).
> 
> Simon

Hi all,

In the perspective of "type identity", the way I see it the issue has a 
few parts:

1) How GCC compiles such templates
2) How GCC emits debugging information via -g
3) How such information is interpreted (and merged with the compiled 
code) by GDB

Regarding 1) and 2), IMHO I think that there should be a one-to-one 
relationship between the compiled code output and debug info:

This means that if GCC compiles such templates into two different 
classes[1], it should generate two different type identifiers.
Conversely, if it compiles the templates into the same class, then a 
single identifier should be emitted for the single class compiled.
(This goes besides the point of what the standard dictates[2])

If I understand it right, currently the issue is that gcc emits two 
types with the same debug identifier.

Regarding 3), I think that after 1) and 2) are set up, GDB should be 
able to find the correct type definition (using the most appropriate 
design choice).

Hope this helps,
Manfred


[1] According to the findings of Simon, this appears to be the case with 
clang, older GCC, and current GCC master. Do I understand this right?

[2] About handling both templates instantiation as a single class, I 
think that if GCC wants to emit a single class, then its argument type 
instantiation should be well-definined,i.e. independent of the order of 
declaration - see the findings from Simon earlier in this thread where 
you could get the program output either -10 or 4294967286 depending on 
which declaration would come first.

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

[Jonathan Wakely]

On 7 February 2018 at 15:07, Manfred <mx2927@gmail.com> wrote:
>
>
> On 02/07/2018 02:44 PM, Simon Marchi wrote:
>>
>> On 2018-02-07 02:21, Daniel Berlin wrote:
>>>
>>> As the person who, eons ago, wrote a bunch of the the GDB code for this
>>> C++
>>> ABI support, and as someone who helped with DWARF support in both GDB and
>>> GCC, let me try to propose a useful path forward (in the hopes that
>>> someone
>>> will say "that's horrible, do it this <clearly better way> instead")
>>>
>>> Here are the constraints i believe we are working with.
>>>
>>> 1. GDB should work with multiple DWARF producers and multiple C++
>>> compilers
>>> implementing the C++ ABI
>>> 2. There is no canonical demangled format for the C++ ABI
>>> 3. There is no canoncial target demangler you can say everyone should use
>>> (and even if there was, you don't want to avoid debugging working because
>>> someone chose not to)
>>> 4. You don't want to slow down GDB if you can avoid it
>>> 5. Despite them all implementation the same ABI, it's still possible to
>>> distinguish the producers by the producer/compiler in the dwarf info.
>>>
>>> Given all that:
>>>
>>> GDB has ABI hooks that tell it what to do for various C++ ABIs. This is
>>> how
>>> it knows to call the right demangler for gcc v3's abi vs gcc v2's abi.
>>> and
>>> handle various differences between them.
>>>
>>> See gdb/cp-abi.h
>>>
>>> The IMHO, obvious thing to do here is: Handle the resulting demangler
>>> differences with 1 or more new C++ ABI hooks.
>>> Or, introduce C++ debuginfo producer hooks that the C++ ABI hooks use if
>>> folks want it to be separate.
>>>
>>> Once the producer is detected, fill in the hooks with a set of functions
>>> that does the right thing.
>>>
>>> I imagine this would also clean up a bundle of hacks in various parts of
>>> gdb trying to handle these differences anyway (which is where a lot of
>>> the
>>> multiple symbol lookups/etc that are often slow come from.
>>> If we just detected and said "this is gcc 6, it behaves like this", we
>>> wouldn't need to do that)
>>>
>>> In case you are worried, you will discover this is how a bunch of stuff
>>> is
>>> done and already contains a ball of hacks.
>>>
>>> Using hooks would be, IMHO, a significant improvement.
>>
>>
>> Hi Daniel,
>>
>> Thanks for chiming in.
>>
>> This addresses the issue of how to do good software design in GDB to
>> support different producers cleanly, but I think we have some issues even
>> before that, like how to support g++ 7.3 and up.  I'll try to summarize the
>> issue quickly.  It's now possible to end up with two templated classes with
>> the same name that differ only by the signedness of their non-type template
>> parameter.  One is Foo<int N> and the other is Foo<unsigned int N> (the 10
>> is unsigned).  Until 7.3, g++ would generate names like Foo<10> for the
>> former and names like Foo<10u> for the later (in the DW_AT_name attribute of
>> the classes' DIEs).  Since 7.3, it produces Foo<10> for both.
>>
>> When GDB wants to know the run time type of an object, it fetches the
>> pointer to its vtable, does a symbol lookup to get the linkage name and
>> demangles it, which gives a string like "vtable for Foo<10>" or "vtable for
>> Foo<10u>".  It strips the "vtable for " and uses the remainder to do a type
>> lookup.  Since g++ 7.3, you can see that doing a type lookup for Foo<10> may
>> find the wrong type, and doing a lookup for Foo<10u> won't find anything.
>>
>> So the problem here is how to uniquely identify those two classes when we
>> are doing this run-time type finding operation (and probably in other cases
>> too).
>>
>> Simon
>
>
> Hi all,
>
> In the perspective of "type identity", the way I see it the issue has a few
> parts:
>
> 1) How GCC compiles such templates
> 2) How GCC emits debugging information via -g
> 3) How such information is interpreted (and merged with the compiled code)
> by GDB
>
> Regarding 1) and 2), IMHO I think that there should be a one-to-one
> relationship between the compiled code output and debug info:
>
> This means that if GCC compiles such templates into two different
> classes[1], it should generate two different type identifiers.

What do you mean by "such templates"? There have been several
different examples in the thread, which should be handled differently.

> Conversely, if it compiles the templates into the same class, then a single
> identifier should be emitted for the single class compiled.
> (This goes besides the point of what the standard dictates[2])
>
> If I understand it right, currently the issue is that gcc emits two types
> with the same debug identifier.
>
> Regarding 3), I think that after 1) and 2) are set up, GDB should be able to
> find the correct type definition (using the most appropriate design choice).
>
> Hope this helps,

Not really :-)

You're basically just saying "GCC and GDB should do the right thing"
which is a statement of the obvious.


> [1] According to the findings of Simon, this appears to be the case with
> clang, older GCC, and current GCC master. Do I understand this right?

As I said above, it's not clear what you're referring to.

> [2] About handling both templates instantiation as a single class, I think
> that if GCC wants to emit a single class, then its argument type
> instantiation should be well-definined,i.e. independent of the order of
> declaration - see the findings from Simon earlier in this thread where you
> could get the program output either -10 or 4294967286 depending on which
> declaration would come first.

That's just a GCC 7 bug in the handling of auto template parameters,
see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79092
It's not really relevant here, and is already fixed on trunk.

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

[Manfred]

On 2/7/2018 4:15 PM, Jonathan Wakely wrote:
> On 7 February 2018 at 15:07, Manfred <mx2927@gmail.com> wrote:
>>
>>
>> On 02/07/2018 02:44 PM, Simon Marchi wrote:
>>>
[...]
>>>
>>> This addresses the issue of how to do good software design in GDB to
>>> support different producers cleanly, but I think we have some issues even
>>> before that, like how to support g++ 7.3 and up.  I'll try to summarize the
>>> issue quickly.  It's now possible to end up with two templated classes with
>>> the same name that differ only by the signedness of their non-type template
>>> parameter.  One is Foo<int N> and the other is Foo<unsigned int N> (the 10
>>> is unsigned).  Until 7.3, g++ would generate names like Foo<10> for the
>>> former and names like Foo<10u> for the later (in the DW_AT_name attribute of
>>> the classes' DIEs).  Since 7.3, it produces Foo<10> for both.
>>>
>>> When GDB wants to know the run time type of an object, it fetches the
>>> pointer to its vtable, does a symbol lookup to get the linkage name and
>>> demangles it, which gives a string like "vtable for Foo<10>" or "vtable for
>>> Foo<10u>".  It strips the "vtable for " and uses the remainder to do a type
>>> lookup.  Since g++ 7.3, you can see that doing a type lookup for Foo<10> may
>>> find the wrong type, and doing a lookup for Foo<10u> won't find anything.
>>>
>>> So the problem here is how to uniquely identify those two classes when we
>>> are doing this run-time type finding operation (and probably in other cases
>>> too).
>>>
>>> Simon
>>
>>
>> Hi all,
>>
>> In the perspective of "type identity", the way I see it the issue has a few
>> parts:
>>
>> 1) How GCC compiles such templates
>> 2) How GCC emits debugging information via -g
>> 3) How such information is interpreted (and merged with the compiled code)
>> by GDB
>>
>> Regarding 1) and 2), IMHO I think that there should be a one-to-one
>> relationship between the compiled code output and debug info:
>>
>> This means that if GCC compiles such templates into two different
>> classes[1], it should generate two different type identifiers.
> 
> What do you mean by "such templates"? There have been several
> different examples in the thread, which should be handled differently.

 From Roman 2/3/2018
#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; };
};

 From Simon 2/4/2018
      base * fi = new foo<10>();
      base * fu = new foo<10u>();


You are right that the original thread was started by Roman with:

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

template< int IVAL, unsigned UVAL, unsigned long long ULLVAL>
struct derived : base {
     int x = IVAL + + UVAL + ULLVAL;
};

> 
>> Conversely, if it compiles the templates into the same class, then a single
>> identifier should be emitted for the single class compiled.
>> (This goes besides the point of what the standard dictates[2])
>>
>> If I understand it right, currently the issue is that gcc emits two types
>> with the same debug identifier.
>>
>> Regarding 3), I think that after 1) and 2) are set up, GDB should be able to
>> find the correct type definition (using the most appropriate design choice).
>>
>> Hope this helps,
> 
> Not really :-)
Sorry for that :-)

> 
> You're basically just saying "GCC and GDB should do the right thing"
> which is a statement of the obvious.
Besides the obvious, the main point was:
"IMHO I think that there should be a one-to-one relationship between the 
compiled code output and debug info"
and:
"If I understand it right, currently the issue is that gcc emits two 
types with the same debug identifier."

Which was an attempt to help by making obvious what I understood was 
going wrong.

> 
> 
>> [1] According to the findings of Simon, this appears to be the case with
>> clang, older GCC, and current GCC master. Do I understand this right?
> 
> As I said above, it's not clear what you're referring to.
I had in mind foo<10> and foo<10u>

After your remark, I realize I should have left out "older GCC" because 
'auto' does not apply to it - older GCC dealt with the initial example:
template< int IVAL, unsigned UVAL, unsigned long long ULLVAL>

> 
>> [2] About handling both templates instantiation as a single class, I think
>> that if GCC wants to emit a single class, then its argument type
>> instantiation should be well-definined,i.e. independent of the order of
>> declaration - see the findings from Simon earlier in this thread where you
>> could get the program output either -10 or 4294967286 depending on which
>> declaration would come first.
> 
> That's just a GCC 7 bug in the handling of auto template parameters,
> see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79092
> It's not really relevant here, and is already fixed on trunk.
> 
Thanks for pointing this out.
If I understand it correctly, the solution of the bug is that foo<10> 
and foo<10u> result in two different classes
(according to your comment #1 in the bug, which by the way I am not sure 
how it plays with the wording of the standard, but that's beyond gdb 
compatibility)

Has -g type identification been differentiated too?

Getting back to auto/non-auto template arguments, I understand they are 
different subjects, still, though, type identification in debug info 
applies to both.

I am just a C++ gcc and gdb user, so I am missing their internals.
I think I'll keep quiet if this leads to unintentional noise.

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

[Michael Matz]

Hi,

On Wed, 7 Feb 2018, Simon Marchi wrote:

> This addresses the issue of how to do good software design in GDB to 
> support different producers cleanly, but I think we have some issues 
> even before that, like how to support g++ 7.3 and up.  I'll try to 
> summarize the issue quickly. It's now possible to end up with two 
> templated classes with the same name that differ only by the signedness 
> of their non-type template parameter.  One is Foo<int N> and the other 
> is Foo<unsigned int N> (the 10 is unsigned).  Until 7.3, g++ would 
> generate names like Foo<10> for the former and names like Foo<10u> for 
> the later (in the DW_AT_name attribute of the classes' DIEs). Since 7.3, 
> it produces Foo<10> for both.

Yeah, gdb needs a way to lookup types by name, and since the change 
DW_AT_name can't be used for this anymore.  Either that needs to be 
fixed/reverted, or we do the more obvious thing: since types in C++ have 
linkage it makes sense to add the linkage (i.e. mangled) name to the types 
DIE using the traditional DW_AT_MIPS_linkage_name.

That latter solution would have the advantage that you don't need to 
demangle anything anymore.  From vtable you get to typeinfo, from there 
for typeinfo name, and that contains the mangled type name (without _Z 
prefix).


Ciao,
Michael.

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

[Simon Marchi]

On 2018-02-07 11:26, Michael Matz wrote:
> Hi,
> 
> On Wed, 7 Feb 2018, Simon Marchi wrote:
> 
>> This addresses the issue of how to do good software design in GDB to
>> support different producers cleanly, but I think we have some issues
>> even before that, like how to support g++ 7.3 and up.  I'll try to
>> summarize the issue quickly. It's now possible to end up with two
>> templated classes with the same name that differ only by the 
>> signedness
>> of their non-type template parameter.  One is Foo<int N> and the other
>> is Foo<unsigned int N> (the 10 is unsigned).  Until 7.3, g++ would
>> generate names like Foo<10> for the former and names like Foo<10u> for
>> the later (in the DW_AT_name attribute of the classes' DIEs). Since 
>> 7.3,
>> it produces Foo<10> for both.
> 
> Yeah, gdb needs a way to lookup types by name, and since the change
> DW_AT_name can't be used for this anymore.  Either that needs to be
> fixed/reverted, or we do the more obvious thing: since types in C++ 
> have
> linkage it makes sense to add the linkage (i.e. mangled) name to the 
> types
> DIE using the traditional DW_AT_MIPS_linkage_name.
> 
> That latter solution would have the advantage that you don't need to
> demangle anything anymore.  From vtable you get to typeinfo, from there
> for typeinfo name, and that contains the mangled type name (without _Z
> prefix).

But do struct/classes have mangled names?

Simon

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

[Jonathan Wakely]

On 7 February 2018 at 16:36, Simon Marchi wrote:
> On 2018-02-07 11:26, Michael Matz wrote:
>>
>> Hi,
>>
>> On Wed, 7 Feb 2018, Simon Marchi wrote:
>>
>>> This addresses the issue of how to do good software design in GDB to
>>> support different producers cleanly, but I think we have some issues
>>> even before that, like how to support g++ 7.3 and up.  I'll try to
>>> summarize the issue quickly. It's now possible to end up with two
>>> templated classes with the same name that differ only by the signedness
>>> of their non-type template parameter.  One is Foo<int N> and the other
>>> is Foo<unsigned int N> (the 10 is unsigned).  Until 7.3, g++ would
>>> generate names like Foo<10> for the former and names like Foo<10u> for
>>> the later (in the DW_AT_name attribute of the classes' DIEs). Since 7.3,
>>> it produces Foo<10> for both.
>>
>>
>> Yeah, gdb needs a way to lookup types by name, and since the change
>> DW_AT_name can't be used for this anymore.  Either that needs to be
>> fixed/reverted, or we do the more obvious thing: since types in C++ have
>> linkage it makes sense to add the linkage (i.e. mangled) name to the types
>> DIE using the traditional DW_AT_MIPS_linkage_name.
>>
>> That latter solution would have the advantage that you don't need to
>> demangle anything anymore.  From vtable you get to typeinfo, from there
>> for typeinfo name, and that contains the mangled type name (without _Z
>> prefix).
>
>
> But do struct/classes have mangled names?

Yes.

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

[Simon Marchi]

On 2018-02-07 11:50, Jonathan Wakely wrote:
> On 7 February 2018 at 16:36, Simon Marchi wrote:
>> On 2018-02-07 11:26, Michael Matz wrote:
>>> 
>>> Hi,
>>> 
>>> On Wed, 7 Feb 2018, Simon Marchi wrote:
>>> 
>>>> This addresses the issue of how to do good software design in GDB to
>>>> support different producers cleanly, but I think we have some issues
>>>> even before that, like how to support g++ 7.3 and up.  I'll try to
>>>> summarize the issue quickly. It's now possible to end up with two
>>>> templated classes with the same name that differ only by the 
>>>> signedness
>>>> of their non-type template parameter.  One is Foo<int N> and the 
>>>> other
>>>> is Foo<unsigned int N> (the 10 is unsigned).  Until 7.3, g++ would
>>>> generate names like Foo<10> for the former and names like Foo<10u> 
>>>> for
>>>> the later (in the DW_AT_name attribute of the classes' DIEs). Since 
>>>> 7.3,
>>>> it produces Foo<10> for both.
>>> 
>>> 
>>> Yeah, gdb needs a way to lookup types by name, and since the change
>>> DW_AT_name can't be used for this anymore.  Either that needs to be
>>> fixed/reverted, or we do the more obvious thing: since types in C++ 
>>> have
>>> linkage it makes sense to add the linkage (i.e. mangled) name to the 
>>> types
>>> DIE using the traditional DW_AT_MIPS_linkage_name.
>>> 
>>> That latter solution would have the advantage that you don't need to
>>> demangle anything anymore.  From vtable you get to typeinfo, from 
>>> there
>>> for typeinfo name, and that contains the mangled type name (without 
>>> _Z
>>> prefix).
>> 
>> 
>> But do struct/classes have mangled names?
> 
> Yes.

Interesting.  What do they look like, and in what context do they 
appear?

Simon

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

[Jonathan Wakely]

On 7 February 2018 at 17:03, Simon Marchi <simon.marchi@polymtl.ca> wrote:
> On 2018-02-07 11:50, Jonathan Wakely wrote:
>>
>> On 7 February 2018 at 16:36, Simon Marchi wrote:
>>>
>>> On 2018-02-07 11:26, Michael Matz wrote:
>>>>
>>>>
>>>> Hi,
>>>>
>>>> On Wed, 7 Feb 2018, Simon Marchi wrote:
>>>>
>>>>> This addresses the issue of how to do good software design in GDB to
>>>>> support different producers cleanly, but I think we have some issues
>>>>> even before that, like how to support g++ 7.3 and up.  I'll try to
>>>>> summarize the issue quickly. It's now possible to end up with two
>>>>> templated classes with the same name that differ only by the signedness
>>>>> of their non-type template parameter.  One is Foo<int N> and the other
>>>>> is Foo<unsigned int N> (the 10 is unsigned).  Until 7.3, g++ would
>>>>> generate names like Foo<10> for the former and names like Foo<10u> for
>>>>> the later (in the DW_AT_name attribute of the classes' DIEs). Since
>>>>> 7.3,
>>>>> it produces Foo<10> for both.
>>>>
>>>>
>>>>
>>>> Yeah, gdb needs a way to lookup types by name, and since the change
>>>> DW_AT_name can't be used for this anymore.  Either that needs to be
>>>> fixed/reverted, or we do the more obvious thing: since types in C++ have
>>>> linkage it makes sense to add the linkage (i.e. mangled) name to the
>>>> types
>>>> DIE using the traditional DW_AT_MIPS_linkage_name.
>>>>
>>>> That latter solution would have the advantage that you don't need to
>>>> demangle anything anymore.  From vtable you get to typeinfo, from there
>>>> for typeinfo name, and that contains the mangled type name (without _Z
>>>> prefix).
>>>
>>>
>>>
>>> But do struct/classes have mangled names?
>>
>>
>> Yes.

Why would they not have a mangled name?

> Interesting.  What do they look like, and in what context do they appear?

Anywhere you need a name for linkage purposes, such as in a function
signature, or as a template argument of another type, or in the
std::type_info::name() for the type etc. etc.

$ g++ -o test.o -c -x c++ - <<< 'struct X {}; void f(X) {}
template<typename T> struct Y { }; void g(Y<X>) {}' && nm
--defined-only test.o
0000000000000000 T _Z1f1X
0000000000000007 T _Z1g1YI1XE

The mangled name for X is "X" and the mangled name for Y<X> is "YI1XE"
which includes the name "X".

This isn't really on-topic for solving the GDB type lookup problem though.

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

[Simon Marchi]

On 2018-02-07 12:08, Jonathan Wakely wrote:
> Why would they not have a mangled name?
> 
>> Interesting.  What do they look like, and in what context do they 
>> appear?
> 
> Anywhere you need a name for linkage purposes, such as in a function
> signature, or as a template argument of another type, or in the
> std::type_info::name() for the type etc. etc.
> 
> $ g++ -o test.o -c -x c++ - <<< 'struct X {}; void f(X) {}
> template<typename T> struct Y { }; void g(Y<X>) {}' && nm
> --defined-only test.o
> 0000000000000000 T _Z1f1X
> 0000000000000007 T _Z1g1YI1XE
> 
> The mangled name for X is "X" and the mangled name for Y<X> is "YI1XE"
> which includes the name "X".
> 
> This isn't really on-topic for solving the GDB type lookup problem 
> though.

Ah ok, the class name appears mangled in other entities' mangled name.  
But from what I understand there's no mangled name for the class such 
that

   echo <class mangled name> | c++filt

outputs the class name (e.g. "Foo<10>").  That wouldn't make sense, 
since there's no symbol for the class itself.

Simon

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

[Jonathan Wakely]

On 7 February 2018 at 17:20, Simon Marchi <simon.marchi@polymtl.ca> wrote:
> On 2018-02-07 12:08, Jonathan Wakely wrote:
>>
>> Why would they not have a mangled name?
>>
>>> Interesting.  What do they look like, and in what context do they appear?
>>
>>
>> Anywhere you need a name for linkage purposes, such as in a function
>> signature, or as a template argument of another type, or in the
>> std::type_info::name() for the type etc. etc.
>>
>> $ g++ -o test.o -c -x c++ - <<< 'struct X {}; void f(X) {}
>> template<typename T> struct Y { }; void g(Y<X>) {}' && nm
>> --defined-only test.o
>> 0000000000000000 T _Z1f1X
>> 0000000000000007 T _Z1g1YI1XE
>>
>> The mangled name for X is "X" and the mangled name for Y<X> is "YI1XE"
>> which includes the name "X".
>>
>> This isn't really on-topic for solving the GDB type lookup problem though.
>
>
> Ah ok, the class name appears mangled in other entities' mangled name.  But
> from what I understand there's no mangled name for the class such that
>
>   echo <class mangled name> | c++filt
>
> outputs the class name (e.g. "Foo<10>").  That wouldn't make sense, since
> there's no symbol for the class itself.

echo _Z3FooILi10EE | c++filt

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

[Simon Marchi]

On 2018-02-07 12:30, Jonathan Wakely wrote:
>> Ah ok, the class name appears mangled in other entities' mangled name. 
>>  But
>> from what I understand there's no mangled name for the class such that
>> 
>>   echo <class mangled name> | c++filt
>> 
>> outputs the class name (e.g. "Foo<10>").  That wouldn't make sense, 
>> since
>> there's no symbol for the class itself.
> 
> echo _Z3FooILi10EE | c++filt

Ok, thanks for the precision!

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

[Michael Matz]

Hi,

On Wed, 7 Feb 2018, Simon Marchi wrote:

> On 2018-02-07 12:30, Jonathan Wakely wrote:
> >> Ah ok, the class name appears mangled in other entities' mangled name. But
> >> from what I understand there's no mangled name for the class such that
> >> 
> >>   echo <class mangled name> | c++filt
> >> 
> >> outputs the class name (e.g. "Foo<10>").  That wouldn't make sense, since
> >> there's no symbol for the class itself.
> > 
> > echo _Z3FooILi10EE | c++filt
> 
> Ok, thanks for the precision!

As I said upthread, the mangled name of a type (sans _Z prefix) is what is 
stored as the type name for RTTI purposes (i.e. std::type_info::name()).

It's just that the debug info currently doesn't have any reference to that 
definitely-unique string, only to the "human-friendly" name, which 
somewhat resembles the demangled name (and that's exactly the crux, it 
really isn't the demangled one right now, as you found out the painful 
way).


Ciao,
Michael.

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

[Paul Smith]

On Thu, 2018-02-08 at 11:26 +0000, Michael Matz wrote:
> As I said upthread, the mangled name of a type (sans _Z prefix) is what is 
> stored as the type name for RTTI purposes (i.e. std::type_info::name()).
> 
> It's just that the debug info currently doesn't have any reference to that 
> definitely-unique string, only to the "human-friendly" name, which 
> somewhat resembles the demangled name (and that's exactly the crux, it 
> really isn't the demangled one right now, as you found out the painful 
> way).

Isn't the problem with the mangled name, which otherwise would be just
what we wanted since it's easy to match and is unique in just the way
we want it to be, that mangling is not standardized?  If GDB relied on
the mangled name it would need to incorporate demanglers for any
compiler that it wanted to be able to debug and figure out which
demangler to use when it was trying to debug a program.  This goes
against the concept of a common debug format like DWARF I would expect.

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

[Jonathan Wakely]

On 8 February 2018 at 14:05, Paul Smith wrote:
> Isn't the problem with the mangled name, which otherwise would be just
> what we wanted since it's easy to match and is unique in just the way
> we want it to be, that mangling is not standardized?

No, because mangling is standardized:
http://itanium-cxx-abi.github.io/cxx-abi/abi.html#mangling

The *demangled* name doesn't have a fixed, canonical form.

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

[Marc Glisse]

On Wed, 7 Feb 2018, Simon Marchi wrote:

> On 2018-02-07 12:08, Jonathan Wakely wrote:
>> Why would they not have a mangled name?
>> 
>>> Interesting.  What do they look like, and in what context do they appear?
>> 
>> Anywhere you need a name for linkage purposes, such as in a function
>> signature, or as a template argument of another type, or in the
>> std::type_info::name() for the type etc. etc.
>> 
>> $ g++ -o test.o -c -x c++ - <<< 'struct X {}; void f(X) {}
>> template<typename T> struct Y { }; void g(Y<X>) {}' && nm
>> --defined-only test.o
>> 0000000000000000 T _Z1f1X
>> 0000000000000007 T _Z1g1YI1XE
>> 
>> The mangled name for X is "X" and the mangled name for Y<X> is "YI1XE"
>> which includes the name "X".
>> 
>> This isn't really on-topic for solving the GDB type lookup problem though.
>
> Ah ok, the class name appears mangled in other entities' mangled name.  But 
> from what I understand there's no mangled name for the class such that
>
>  echo <class mangled name> | c++filt
>
> outputs the class name (e.g. "Foo<10>").  That wouldn't make sense, since 
> there's no symbol for the class itself.

$ echo _Z1YI1XE | c++filt
Y<X>

-- 
Marc Glisse

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

[Daniel Berlin]

On Wed, Feb 7, 2018 at 5:44 AM, Simon Marchi <simon.marchi@polymtl.ca>
wrote:

> On 2018-02-07 02:21, Daniel Berlin wrote:
>
>> As the person who, eons ago, wrote a bunch of the the GDB code for this
>> C++
>> ABI support, and as someone who helped with DWARF support in both GDB and
>> GCC, let me try to propose a useful path forward (in the hopes that
>> someone
>> will say "that's horrible, do it this <clearly better way> instead")
>>
>> Here are the constraints i believe we are working with.
>>
>> 1. GDB should work with multiple DWARF producers and multiple C++
>> compilers
>> implementing the C++ ABI
>> 2. There is no canonical demangled format for the C++ ABI
>> 3. There is no canoncial target demangler you can say everyone should use
>> (and even if there was, you don't want to avoid debugging working because
>> someone chose not to)
>> 4. You don't want to slow down GDB if you can avoid it
>> 5. Despite them all implementation the same ABI, it's still possible to
>> distinguish the producers by the producer/compiler in the dwarf info.
>>
>> Given all that:
>>
>> GDB has ABI hooks that tell it what to do for various C++ ABIs. This is
>> how
>> it knows to call the right demangler for gcc v3's abi vs gcc v2's abi. and
>> handle various differences between them.
>>
>> See gdb/cp-abi.h
>>
>> The IMHO, obvious thing to do here is: Handle the resulting demangler
>> differences with 1 or more new C++ ABI hooks.
>> Or, introduce C++ debuginfo producer hooks that the C++ ABI hooks use if
>> folks want it to be separate.
>>
>> Once the producer is detected, fill in the hooks with a set of functions
>> that does the right thing.
>>
>> I imagine this would also clean up a bundle of hacks in various parts of
>> gdb trying to handle these differences anyway (which is where a lot of the
>> multiple symbol lookups/etc that are often slow come from.
>> If we just detected and said "this is gcc 6, it behaves like this", we
>> wouldn't need to do that)
>>
>> In case you are worried, you will discover this is how a bunch of stuff is
>> done and already contains a ball of hacks.
>>
>> Using hooks would be, IMHO, a significant improvement.
>>
>
> Hi Daniel,
>
> Thanks for chiming in.
>
> This addresses the issue of how to do good software design in GDB to
> support different producers cleanly, but I think we have some issues even
> before that, like how to support g++ 7.3 and up.


They are, IMHO, the same.


> I'll try to summarize the issue quickly.  It's now possible to end up with
> two templated classes with the same name that differ only by the signedness
> of their non-type template parameter.


Yup.


>   One is Foo<int N> and the other is Foo<unsigned int N> (the 10 is
> unsigned).  Until 7.3, g++ would generate names like Foo<10> for the former
> and names like Foo<10u> for the later (in the DW_AT_name attribute of the
> classes' DIEs).  Since 7.3, it produces Foo<10> for both.
>
> When GDB wants to know the run time type of an object, it fetches the
> pointer to its vtable, does a symbol lookup to get the linkage name and
> demangles it,


Yes, this is code i wrote :)


> which gives a string like "vtable for Foo<10>" or "vtable for Foo<10u>".
> It strips the "vtable for " and uses the remainder to do a type lookup.
> Since g++ 7.3, you can see that doing a type lookup for Foo<10> may find
> the wrong type,

Certainly if you can't distinguish the types you are screwed, but this  is
not the only way to find this type. This was in fact, the first hack i
thought up to make it work because the ABI was not entirely fully formed at
the time, and the debug info did not have fully qualified names.

Here is a different way that should produce more consistent results.

Find the linker symbol
look up the symbol in the dwarf info by address.
This will give you the vtable type debug info.
Look at the name attribute of the debug info, which should already be
demangled.

Strip the "vtable for" from that.
Look that up.

This avoids the problem of the demangler gdb is using getting a different
name than the producer used. It also should always give you the right one.
If the producer calls the type "vtable fo Foo<2u>" here and "Foo<2>"
elsewhere, yes, that's a bug. It should be consistent.

If there are multiple types named Foo<2u>, DWARF needs to be extended to
allow a pointer from the vtable debug info to the class type debug info
(unless they already added one).
Then you would do *no* symbol lookups, you'd follow that pointer (gdb would
add it to the symbol_info structure)



> and doing a lookup for Foo<10u> won't find anything.
>

Correct.  This stripping is a hook that does the stripping and  lookup in
gnuv3_rtti_type.

That is not the only way yo to it.



>
> So the problem here is how to uniquely identify those two classes when we
> are doing this run-time type finding operation (and probably in other cases
> too).



>
>
> Simon
>

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

[Daniel Berlin]

>
>
> This avoids the problem of the demangler gdb is using getting a different
> name than the producer used. It also should always give you the right one.
> If the producer calls the type "vtable fo Foo<2u>" here and "Foo<2>"
> elsewhere, yes, that's a bug. It should be consistent.
>
>
This should be Foo<2u> vs Foo<2>


> If there are multiple types named Foo<2u>, DWARF needs to be extended to
> allow a pointer from the vtable debug info to the class type debug info
> (unless they already added one).
> Then you would do *no* symbol lookups, you'd follow that pointer (gdb
> would add it to the symbol_info structure)
>

Note that the ABI is explicitly designed so that type identity can be done
by address comparison.

Also note that adding alternative names for symbols is probably a "not
great" idea, though it would work. The *vast* majority of debug info is in
those names, and adding long names will often triple or quadruple the size
of debug info.
Google has binaries where 90% of the size is in gigabytes of linkage
names.  People have worked hard to need the names *less*.

So you want to get *away* from going by name, especially when the compiler
knows "this is the vtable that goes with this type". It should just tell
you.
Right now, that is what you are missing "given a vtable for a type, how do
i get the type".

Trying to do that by name is a hack. A hack that has lasted 15+ years mind
you, but still a hack.

I would just kill that hack.

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

[Nathan Sidwell]

On 02/07/2018 12:11 PM, Daniel Berlin wrote:

> 
> Note that the ABI is explicitly designed so that type identity can be done
> by address comparison.

correct, but be aware that lots of dynamic objects seem to step outside 
the ABI by building shared objects with -Bsymbolic[1], or the equivalent 
visibility=hidden, or similar.  So now the typeinfo comparison operator 
is something like
   return this->name == other->name
   || (this->name[0] != '*' && other->name[0] != '*'
       && !strcmp (this->name, other->name))

nathan
[1] I see -Bsymbolic-functions is now a thing, which would be better

-- 
Nathan Sidwell

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

[Tom Tromey]

>>>>> "Dan" == Daniel Berlin <dberlin@dberlin.org> writes:

Dan> If there are multiple types named Foo<2u>, DWARF needs to be extended to
Dan> allow a pointer from the vtable debug info to the class type debug info
Dan> (unless they already added one).

This is what we did for Rust.

Rust doesn't have a stable ABI yet, so using gdb's current approach --
having the debugger use details of the ABI in addition to the debug info
-- wasn't an option.

So, instead, the Rust compiler emits DWARF for the vtable and associates
the vtable with the concrete type for which it was emitted.  This
required a minor DWARF extension.

I think C++ could probably do something along these lines as well.

The current gdb approach hasn't been really solid since function-local
classes were added to C++.  IIRC there are bugs in gdb bugzilla about
this.  These kinds of problems are, I think, completely avoided by a
DWARF-based approach.

Tom

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

[Richard Biener]

On Mon, Feb 5, 2018 at 6:06 AM, Simon Marchi <simon.marchi@polymtl.ca> wrote:
> Hi Martin,
>
> Thanks for the reply.
>
> On 2018-02-04 02:17 PM, Martin Sebor wrote:
>> Printing the suffix is unhelpful because it leads to unnecessary
>> differences in diagnostics (even in non-template contexts).  For
>> templates with non-type template parameters there is no difference
>> between, say A<1>, A<1U>, A<(unsigned) 1>, or even A<Green> when
>> Green is an enumerator that evaluates to 1, so including the suffix
>> serves no useful purpose.
>
> This is the part I don't understand.  In Roman's example, spelling
> foo<10> and foo<10u> resulted in two different instantiations of the
> template, with different code.  So that means it can make a difference,
> can't it?
>
>> In the GCC test suite, it would tend to
>> cause failures due to differences between the underlying type of
>> common typedefs like size_t and ptrdiff_t.  Avoiding these
>> unnecessary differences was the main motivation for the change.
>> Not necessarily just in the GCC test suite but in all setups that
>> process GCC messages.
>
> Ok, I understand.
>
>> I didn't consider the use of auto as a template parameter but
>> I don't think it changes anything.  There, just like in other
>> contexts, what's important is the deduced types and the values
>> of constants, not the minute details of how they are spelled.
>
> Well, it seems like using decltype on a template constant value is
> a way to make the type of constants important, in addition to their
> value.  I know the standard seems to say otherwise (what Manfred
> quoted), but the reality seems different.  I'm not a language expert
> so I can't tell if this is a deficiency in the language or not.
>
>> That said, it wasn't my intention to make things difficult for
>> the debugger.
>
> I hope so :).
>
>> But changing GCC back to include the suffix,
>> even just in the debug info, isn't a solution.  There are other
>> compilers besides GCC that don't emit the suffixes, and there
>> even are some that prepend a cast to the number, so if GDB is
>> to be usable with all these kinds of producers it needs to be
>> able to handle all of these forms.
>
> As I said earlier, there are probably ways to make GDB cope with it.
> The only solution I saw (I'd like to hear about other ones) was to make
> GDB ignore the template part in DW_AT_name and re-build it from the
> DW_TAG_template_* DIEs in the format it expects.  It can already do
> that somewhat, because, as you said, some compilers don't emit
> the template part in DW_AT_name.
>
> Doing so would cause major slowdowns in symbol reading, I've tried it
> for the sake of experimentation/discussion.  I have a patch available
> on the "users/simark/template-suffix" branch in the binutils-gdb
> repo [1].  It works for Roman's example, but running the GDB testsuite
> shows that, of course, the devil is in the details.
>
> Consider something like this:
>
>   template <int *P>
>   struct foo { virtual ~foo() {} };
>
>   int n;
>
>   int main ()
>   {
>     foo<&n> f;
>   }
>
>
> The demangled name that GDB will be looking up is "foo<&n>".  The
> debug info about the template parameter only contains the resulting
> address of n (the value of &n):
>
>  <2><bf>: Abbrev Number: 11 (DW_TAG_template_value_param)
>     <c0>   DW_AT_name        : P
>     <c2>   DW_AT_type        : <0x1ac>
>     <c6>   DW_AT_location    : 10 byte block: 3 34 10 60 0 0 0 0 0 9f   (DW_OP_addr: 601034; DW_OP_stack_value)
>
> I don't see how GDB could reconstruct the "&n" in the template, so
> that's where my idea falls short.

For other reasons I've always wanted sth like

  DW_OP_addr; DW_OP_name: n; DW_OP_stack_value

thus put symbolical expressions in locations and have the consumer look them up
(in context obviously).  That way gdb can also choose to print foo<n> instead of
foo<1> or foo<<optimized out>>.

Of course that needs DWARF extensions.

Richard.

> Simon
>
> [1] https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=shortlog;h=refs/heads/users/simark/template-suffix

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

[Roman Popov]

Is there any progress on this problem?

I'm not familiar with G++ , but I have little experience with LLVM.  I can
try make LLVM emitting mangled names to DW_AT_name, instead of demangled
ones.
This way GDB can match DW_AT_name against RTTI. And for display it can
call  abi::__cxa_demangle(name, NULL, NULL, &status), from #include
<cxxabi.h>.

Will it work?

Thanks, Roman


2018-02-08 7:05 GMT-08:00 Richard Biener <richard.guenther@gmail.com>:

> On Mon, Feb 5, 2018 at 6:06 AM, Simon Marchi <simon.marchi@polymtl.ca>
> wrote:
> > Hi Martin,
> >
> > Thanks for the reply.
> >
> > On 2018-02-04 02:17 PM, Martin Sebor wrote:
> >> Printing the suffix is unhelpful because it leads to unnecessary
> >> differences in diagnostics (even in non-template contexts).  For
> >> templates with non-type template parameters there is no difference
> >> between, say A<1>, A<1U>, A<(unsigned) 1>, or even A<Green> when
> >> Green is an enumerator that evaluates to 1, so including the suffix
> >> serves no useful purpose.
> >
> > This is the part I don't understand.  In Roman's example, spelling
> > foo<10> and foo<10u> resulted in two different instantiations of the
> > template, with different code.  So that means it can make a difference,
> > can't it?
> >
> >> In the GCC test suite, it would tend to
> >> cause failures due to differences between the underlying type of
> >> common typedefs like size_t and ptrdiff_t.  Avoiding these
> >> unnecessary differences was the main motivation for the change.
> >> Not necessarily just in the GCC test suite but in all setups that
> >> process GCC messages.
> >
> > Ok, I understand.
> >
> >> I didn't consider the use of auto as a template parameter but
> >> I don't think it changes anything.  There, just like in other
> >> contexts, what's important is the deduced types and the values
> >> of constants, not the minute details of how they are spelled.
> >
> > Well, it seems like using decltype on a template constant value is
> > a way to make the type of constants important, in addition to their
> > value.  I know the standard seems to say otherwise (what Manfred
> > quoted), but the reality seems different.  I'm not a language expert
> > so I can't tell if this is a deficiency in the language or not.
> >
> >> That said, it wasn't my intention to make things difficult for
> >> the debugger.
> >
> > I hope so :).
> >
> >> But changing GCC back to include the suffix,
> >> even just in the debug info, isn't a solution.  There are other
> >> compilers besides GCC that don't emit the suffixes, and there
> >> even are some that prepend a cast to the number, so if GDB is
> >> to be usable with all these kinds of producers it needs to be
> >> able to handle all of these forms.
> >
> > As I said earlier, there are probably ways to make GDB cope with it.
> > The only solution I saw (I'd like to hear about other ones) was to make
> > GDB ignore the template part in DW_AT_name and re-build it from the
> > DW_TAG_template_* DIEs in the format it expects.  It can already do
> > that somewhat, because, as you said, some compilers don't emit
> > the template part in DW_AT_name.
> >
> > Doing so would cause major slowdowns in symbol reading, I've tried it
> > for the sake of experimentation/discussion.  I have a patch available
> > on the "users/simark/template-suffix" branch in the binutils-gdb
> > repo [1].  It works for Roman's example, but running the GDB testsuite
> > shows that, of course, the devil is in the details.
> >
> > Consider something like this:
> >
> >   template <int *P>
> >   struct foo { virtual ~foo() {} };
> >
> >   int n;
> >
> >   int main ()
> >   {
> >     foo<&n> f;
> >   }
> >
> >
> > The demangled name that GDB will be looking up is "foo<&n>".  The
> > debug info about the template parameter only contains the resulting
> > address of n (the value of &n):
> >
> >  <2><bf>: Abbrev Number: 11 (DW_TAG_template_value_param)
> >     <c0>   DW_AT_name        : P
> >     <c2>   DW_AT_type        : <0x1ac>
> >     <c6>   DW_AT_location    : 10 byte block: 3 34 10 60 0 0 0 0 0 9f
>  (DW_OP_addr: 601034; DW_OP_stack_value)
> >
> > I don't see how GDB could reconstruct the "&n" in the template, so
> > that's where my idea falls short.
>
> For other reasons I've always wanted sth like
>
>   DW_OP_addr; DW_OP_name: n; DW_OP_stack_value
>
> thus put symbolical expressions in locations and have the consumer look
> them up
> (in context obviously).  That way gdb can also choose to print foo<n>
> instead of
> foo<1> or foo<<optimized out>>.
>
> Of course that needs DWARF extensions.
>
> Richard.
>
> > Simon
> >
> > [1] https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;
> a=shortlog;h=refs/heads/users/simark/template-suffix
>

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

[Andrew Pinski]

On Thu, Mar 1, 2018 at 12:18 PM, Roman Popov <ripopov@gmail.com> wrote:
> Is there any progress on this problem?
>
> I'm not familiar with G++ , but I have little experience with LLVM.  I can
> try make LLVM emitting mangled names to DW_AT_name, instead of demangled
> ones.
> This way GDB can match DW_AT_name against RTTI. And for display it can
> call  abi::__cxa_demangle(name, NULL, NULL, &status), from #include
> <cxxabi.h>.
>
> Will it work?


Reading http://wiki.dwarfstd.org/index.php?title=Best_Practices:
the DW_AT_name attribute should contain the name of the corresponding
program object as it appears in the source code, without any
qualifiers such as namespaces, containing classes, or modules (see
Section 2.15). A consumer can easily reconstruct the fully-qualified
name from the DIE hierarchy. In general, the value of DW_AT_name
should be such that a fully-qualified name constructed from the
DW_AT_name attributes of the object and its containing objects will
uniquely represent that object in a form natural to the source
language.


So having the mangled symbol in DW_AT_name seems backwards and not the
point of it.

Thanks,
Andrew

>
> Thanks, Roman
>
>
> 2018-02-08 7:05 GMT-08:00 Richard Biener <richard.guenther@gmail.com>:
>
>> On Mon, Feb 5, 2018 at 6:06 AM, Simon Marchi <simon.marchi@polymtl.ca>
>> wrote:
>> > Hi Martin,
>> >
>> > Thanks for the reply.
>> >
>> > On 2018-02-04 02:17 PM, Martin Sebor wrote:
>> >> Printing the suffix is unhelpful because it leads to unnecessary
>> >> differences in diagnostics (even in non-template contexts).  For
>> >> templates with non-type template parameters there is no difference
>> >> between, say A<1>, A<1U>, A<(unsigned) 1>, or even A<Green> when
>> >> Green is an enumerator that evaluates to 1, so including the suffix
>> >> serves no useful purpose.
>> >
>> > This is the part I don't understand.  In Roman's example, spelling
>> > foo<10> and foo<10u> resulted in two different instantiations of the
>> > template, with different code.  So that means it can make a difference,
>> > can't it?
>> >
>> >> In the GCC test suite, it would tend to
>> >> cause failures due to differences between the underlying type of
>> >> common typedefs like size_t and ptrdiff_t.  Avoiding these
>> >> unnecessary differences was the main motivation for the change.
>> >> Not necessarily just in the GCC test suite but in all setups that
>> >> process GCC messages.
>> >
>> > Ok, I understand.
>> >
>> >> I didn't consider the use of auto as a template parameter but
>> >> I don't think it changes anything.  There, just like in other
>> >> contexts, what's important is the deduced types and the values
>> >> of constants, not the minute details of how they are spelled.
>> >
>> > Well, it seems like using decltype on a template constant value is
>> > a way to make the type of constants important, in addition to their
>> > value.  I know the standard seems to say otherwise (what Manfred
>> > quoted), but the reality seems different.  I'm not a language expert
>> > so I can't tell if this is a deficiency in the language or not.
>> >
>> >> That said, it wasn't my intention to make things difficult for
>> >> the debugger.
>> >
>> > I hope so :).
>> >
>> >> But changing GCC back to include the suffix,
>> >> even just in the debug info, isn't a solution.  There are other
>> >> compilers besides GCC that don't emit the suffixes, and there
>> >> even are some that prepend a cast to the number, so if GDB is
>> >> to be usable with all these kinds of producers it needs to be
>> >> able to handle all of these forms.
>> >
>> > As I said earlier, there are probably ways to make GDB cope with it.
>> > The only solution I saw (I'd like to hear about other ones) was to make
>> > GDB ignore the template part in DW_AT_name and re-build it from the
>> > DW_TAG_template_* DIEs in the format it expects.  It can already do
>> > that somewhat, because, as you said, some compilers don't emit
>> > the template part in DW_AT_name.
>> >
>> > Doing so would cause major slowdowns in symbol reading, I've tried it
>> > for the sake of experimentation/discussion.  I have a patch available
>> > on the "users/simark/template-suffix" branch in the binutils-gdb
>> > repo [1].  It works for Roman's example, but running the GDB testsuite
>> > shows that, of course, the devil is in the details.
>> >
>> > Consider something like this:
>> >
>> >   template <int *P>
>> >   struct foo { virtual ~foo() {} };
>> >
>> >   int n;
>> >
>> >   int main ()
>> >   {
>> >     foo<&n> f;
>> >   }
>> >
>> >
>> > The demangled name that GDB will be looking up is "foo<&n>".  The
>> > debug info about the template parameter only contains the resulting
>> > address of n (the value of &n):
>> >
>> >  <2><bf>: Abbrev Number: 11 (DW_TAG_template_value_param)
>> >     <c0>   DW_AT_name        : P
>> >     <c2>   DW_AT_type        : <0x1ac>
>> >     <c6>   DW_AT_location    : 10 byte block: 3 34 10 60 0 0 0 0 0 9f
>>  (DW_OP_addr: 601034; DW_OP_stack_value)
>> >
>> > I don't see how GDB could reconstruct the "&n" in the template, so
>> > that's where my idea falls short.
>>
>> For other reasons I've always wanted sth like
>>
>>   DW_OP_addr; DW_OP_name: n; DW_OP_stack_value
>>
>> thus put symbolical expressions in locations and have the consumer look
>> them up
>> (in context obviously).  That way gdb can also choose to print foo<n>
>> instead of
>> foo<1> or foo<<optimized out>>.
>>
>> Of course that needs DWARF extensions.
>>
>> Richard.
>>
>> > Simon
>> >
>> > [1] https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;
>> a=shortlog;h=refs/heads/users/simark/template-suffix
>>

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

[Jason Merrill]

On Thu, Mar 1, 2018 at 3:26 PM, Andrew Pinski <pinskia@gmail.com> wrote:
> On Thu, Mar 1, 2018 at 12:18 PM, Roman Popov <ripopov@gmail.com> wrote:
>> Is there any progress on this problem?
>>
>> I'm not familiar with G++ , but I have little experience with LLVM.  I can
>> try make LLVM emitting mangled names to DW_AT_name, instead of demangled
>> ones.
>> This way GDB can match DW_AT_name against RTTI. And for display it can
>> call  abi::__cxa_demangle(name, NULL, NULL, &status), from #include
>> <cxxabi.h>.
>>
>> Will it work?
>
>
> Reading http://wiki.dwarfstd.org/index.php?title=Best_Practices:
> the DW_AT_name attribute should contain the name of the corresponding
> program object as it appears in the source code, without any
> qualifiers such as namespaces, containing classes, or modules (see
> Section 2.15). A consumer can easily reconstruct the fully-qualified
> name from the DIE hierarchy. In general, the value of DW_AT_name
> should be such that a fully-qualified name constructed from the
> DW_AT_name attributes of the object and its containing objects will
> uniquely represent that object in a form natural to the source
> language.
>
>
> So having the mangled symbol in DW_AT_name seems backwards and not the
> point of it.

If we add the mangled name, which seems reasonable, it should be in
DW_AT_linkage_name.

Jason

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

[Roman Popov]

Ok, sounds reasonable. In case of debugger we are indeed "linking" RTTI
name with name in debuginfo.

I've checked LLVM docs, they generate Debuginfo from LLVM "Metadata", and
metadata for types already contains mangled names in "identifier" field:
https://llvm.org/docs/LangRef.html#dicompositetype . So it should not be
hard to propagate it to object file.

I will ask on LLVM maillist if they can emit it.


2018-03-01 13:03 GMT-08:00 Jason Merrill <jason@redhat.com>:

> On Thu, Mar 1, 2018 at 3:26 PM, Andrew Pinski <pinskia@gmail.com> wrote:
> > On Thu, Mar 1, 2018 at 12:18 PM, Roman Popov <ripopov@gmail.com> wrote:
> >> Is there any progress on this problem?
> >>
> >> I'm not familiar with G++ , but I have little experience with LLVM.  I
> can
> >> try make LLVM emitting mangled names to DW_AT_name, instead of demangled
> >> ones.
> >> This way GDB can match DW_AT_name against RTTI. And for display it can
> >> call  abi::__cxa_demangle(name, NULL, NULL, &status), from #include
> >> <cxxabi.h>.
> >>
> >> Will it work?
> >
> >
> > Reading http://wiki.dwarfstd.org/index.php?title=Best_Practices:
> > the DW_AT_name attribute should contain the name of the corresponding
> > program object as it appears in the source code, without any
> > qualifiers such as namespaces, containing classes, or modules (see
> > Section 2.15). A consumer can easily reconstruct the fully-qualified
> > name from the DIE hierarchy. In general, the value of DW_AT_name
> > should be such that a fully-qualified name constructed from the
> > DW_AT_name attributes of the object and its containing objects will
> > uniquely represent that object in a form natural to the source
> > language.
> >
> >
> > So having the mangled symbol in DW_AT_name seems backwards and not the
> > point of it.
>
> If we add the mangled name, which seems reasonable, it should be in
> DW_AT_linkage_name.
>
> Jason
>

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

[Roman Popov]

I've experimented with adding  DW_AT_linkage_name for composite types in
LLVM.  Here is impact on binary sizes (compiled with debuginfo):

            Original size     with DW_AT_linkage_name for composites
 % increase
clang-7.0    1926574256                     1952846192
 1.4%
clang-tidy   1220980360                     1238498112
 1.4%
llvm-mt         7404728                        7525328
 1.6%
cout<<"hello";    21552 22080   2.4%

-Roman


2018-03-02 15:06 GMT-08:00 Roman Popov <ripopov@gmail.com>:

> Ok, sounds reasonable. In case of debugger we are indeed "linking" RTTI
> name with name in debuginfo.
>
> I've checked LLVM docs, they generate Debuginfo from LLVM "Metadata", and
> metadata for types already contains mangled names in "identifier" field:
> https://llvm.org/docs/LangRef.html#dicompositetype . So it should not be
> hard to propagate it to object file.
>
> I will ask on LLVM maillist if they can emit it.
>
>
> 2018-03-01 13:03 GMT-08:00 Jason Merrill <jason@redhat.com>:
>
>> On Thu, Mar 1, 2018 at 3:26 PM, Andrew Pinski <pinskia@gmail.com> wrote:
>> > On Thu, Mar 1, 2018 at 12:18 PM, Roman Popov <ripopov@gmail.com> wrote:
>> >> Is there any progress on this problem?
>> >>
>> >> I'm not familiar with G++ , but I have little experience with LLVM.  I
>> can
>> >> try make LLVM emitting mangled names to DW_AT_name, instead of
>> demangled
>> >> ones.
>> >> This way GDB can match DW_AT_name against RTTI. And for display it can
>> >> call  abi::__cxa_demangle(name, NULL, NULL, &status), from #include
>> >> <cxxabi.h>.
>> >>
>> >> Will it work?
>> >
>> >
>> > Reading http://wiki.dwarfstd.org/index.php?title=Best_Practices:
>> > the DW_AT_name attribute should contain the name of the corresponding
>> > program object as it appears in the source code, without any
>> > qualifiers such as namespaces, containing classes, or modules (see
>> > Section 2.15). A consumer can easily reconstruct the fully-qualified
>> > name from the DIE hierarchy. In general, the value of DW_AT_name
>> > should be such that a fully-qualified name constructed from the
>> > DW_AT_name attributes of the object and its containing objects will
>> > uniquely represent that object in a form natural to the source
>> > language.
>> >
>> >
>> > So having the mangled symbol in DW_AT_name seems backwards and not the
>> > point of it.
>>
>> If we add the mangled name, which seems reasonable, it should be in
>> DW_AT_linkage_name.
>>
>> Jason
>>
>
>

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

[Daniel Berlin]

Again, please don't do this.
As you can see (see Tom Tromey's email), others have a use to go between
vtable types and the types they are attached to.
We should be getting away from linkage names, not going further towards
them.
There are a bunch of gdb bugs this won't solve, but adding an extension
(like tom did for rust) to go between vtable types and concrete types will
solve *all* of them, be *much faster* than what gdb does now, and have
basically *no* space increase at all.

Meanwhile, i can hand you binaries where the size increase is in the
hundreds of megabytes to gigabytes for adding linkage names.



On Fri, Mar 2, 2018 at 3:06 PM, Roman Popov <ripopov@gmail.com> wrote:

> Ok, sounds reasonable. In case of debugger we are indeed "linking" RTTI
> name with name in debuginfo.
>
> I've checked LLVM docs, they generate Debuginfo from LLVM "Metadata", and
> metadata for types already contains mangled names in "identifier" field:
> https://llvm.org/docs/LangRef.html#dicompositetype . So it should not be
> hard to propagate it to object file.
>
> I will ask on LLVM maillist if they can emit it.
>
>
> 2018-03-01 13:03 GMT-08:00 Jason Merrill <jason@redhat.com>:
>
> > On Thu, Mar 1, 2018 at 3:26 PM, Andrew Pinski <pinskia@gmail.com> wrote:
> > > On Thu, Mar 1, 2018 at 12:18 PM, Roman Popov <ripopov@gmail.com>
> wrote:
> > >> Is there any progress on this problem?
> > >>
> > >> I'm not familiar with G++ , but I have little experience with LLVM.  I
> > can
> > >> try make LLVM emitting mangled names to DW_AT_name, instead of
> demangled
> > >> ones.
> > >> This way GDB can match DW_AT_name against RTTI. And for display it can
> > >> call  abi::__cxa_demangle(name, NULL, NULL, &status), from #include
> > >> <cxxabi.h>.
> > >>
> > >> Will it work?
> > >
> > >
> > > Reading http://wiki.dwarfstd.org/index.php?title=Best_Practices:
> > > the DW_AT_name attribute should contain the name of the corresponding
> > > program object as it appears in the source code, without any
> > > qualifiers such as namespaces, containing classes, or modules (see
> > > Section 2.15). A consumer can easily reconstruct the fully-qualified
> > > name from the DIE hierarchy. In general, the value of DW_AT_name
> > > should be such that a fully-qualified name constructed from the
> > > DW_AT_name attributes of the object and its containing objects will
> > > uniquely represent that object in a form natural to the source
> > > language.
> > >
> > >
> > > So having the mangled symbol in DW_AT_name seems backwards and not the
> > > point of it.
> >
> > If we add the mangled name, which seems reasonable, it should be in
> > DW_AT_linkage_name.
> >
> > Jason
> >
>

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

[Jonathan Wakely]

On 4 February 2018 at 19:17, Martin Sebor wrote:
> I think this message would be the most meaningful if the "auto"
> part were replaced with the deduced type.  With that, the suffix
> of the constant isn't important, just as in other contexts.
>
> I didn't consider the use of auto as a template parameter but
> I don't think it changes anything.  There, just like in other
> contexts, what's important is the deduced types and the values
> of constants, not the minute details of how they are spelled.
>
> That said, it wasn't my intention to make things difficult for
> the debugger.  But changing GCC back to include the suffix,
> even just in the debug info, isn't a solution.  There are other
> compilers besides GCC that don't emit the suffixes, and there
> even are some that prepend a cast to the number, so if GDB is
> to be usable with all these kinds of producers it needs to be
> able to handle all of these forms.

The change is a little unfortunate, I pointed out the problems for
debuginfo and template<auto> recently in another context:
https://sourceware.org/bugzilla/show_bug.cgi?id=21492#c1

As I said there, simply comparing strings from the debuginfo is
insufficient for Clang anyway. Now it is for GCC too.

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

[Jonathan Wakely]

On 4 February 2018 at 05:01, Simon Marchi wrote:
> On 2018-02-03 13:35, Manfred wrote:
>> 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.
>
> I think that Roman's example clearly shows that they are not equivalent in
> all cases.
>
> Building Roman's example with g++ 7.3 results in a single instantiated type.  You
> can see that both "new foo<10>()" and "new foo<10u>()" end up calling the same
> constructor.  It seems like which type is instantiated depends on which template
> parameter (the signed or unsigned one) you use first.  So with this:
>
>      base * fi = new foo<10>();
>      base * fu = new foo<10u>();
>
> the output is -10 for both, and with
>
>      base * fu = new foo<10u>();
>      base * fi = new foo<10>();
>
> the output is 4294967286 for both.  But it's probably a bogus behavior.  I tested
> with clangd, it instantiates two different types, so you get 4294967286 for the
> <10u> case and -10 for the <10> case.  I also just built gcc from master, and it
> also instantiates two types, so it seems like that was fixed recently.

That was https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79092 FWIW