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

Simon Marchi
2018-02-05T16:59:25Z

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