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