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

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