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

[Roman Popov <ripopov at gmail dot com>]

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
>