This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]