This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC 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/04/2018 10:06 PM, Simon Marchi wrote:
Hi Martin,

Thanks for the reply.

On 2018-02-04 02:17 PM, Martin Sebor wrote:
Printing the suffix is unhelpful because it leads to unnecessary
differences in diagnostics (even in non-template contexts).  For
templates with non-type template parameters there is no difference
between, say A<1>, A<1U>, A<(unsigned) 1>, or even A<Green> when
Green is an enumerator that evaluates to 1, so including the suffix
serves no useful purpose.

This is the part I don't understand.  In Roman's example, spelling
foo<10> and foo<10u> resulted in two different instantiations of the
template, with different code.  So that means it can make a difference,
can't it?

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.

In the GCC test suite, it would tend to
cause failures due to differences between the underlying type of
common typedefs like size_t and ptrdiff_t.  Avoiding these
unnecessary differences was the main motivation for the change.
Not necessarily just in the GCC test suite but in all setups that
process GCC messages.

Ok, I understand.

I didn't consider the use of auto as a template parameter but
I don't think it changes anything.  There, just like in other
contexts, what's important is the deduced types and the values
of constants, not the minute details of how they are spelled.

Well, it seems like using decltype on a template constant value is
a way to make the type of constants important, in addition to their
value.  I know the standard seems to say otherwise (what Manfred
quoted), but the reality seems different.  I'm not a language expert
so I can't tell if this is a deficiency in the language or not.

That said, it wasn't my intention to make things difficult for
the debugger.

I hope so :).

But changing GCC back to include the suffix,
even just in the debug info, isn't a solution.  There are other
compilers besides GCC that don't emit the suffixes, and there
even are some that prepend a cast to the number, so if GDB is
to be usable with all these kinds of producers it needs to be
able to handle all of these forms.

As I said earlier, there are probably ways to make GDB cope with it.
The only solution I saw (I'd like to hear about other ones) was to make
GDB ignore the template part in DW_AT_name and re-build it from the
DW_TAG_template_* DIEs in the format it expects.  It can already do
that somewhat, because, as you said, some compilers don't emit
the template part in DW_AT_name.

Doing so would cause major slowdowns in symbol reading, I've tried it
for the sake of experimentation/discussion.  I have a patch available
on the "users/simark/template-suffix" branch in the binutils-gdb
repo [1].  It works for Roman's example, but running the GDB testsuite
shows that, of course, the devil is in the details.

Consider something like this:

  template <int *P>
  struct foo { virtual ~foo() {} };

  int n;

  int main ()
  {
    foo<&n> f;
  }


The demangled name that GDB will be looking up is "foo<&n>".  The
debug info about the template parameter only contains the resulting
address of n (the value of &n):

 <2><bf>: Abbrev Number: 11 (DW_TAG_template_value_param)
    <c0>   DW_AT_name        : P
    <c2>   DW_AT_type        : <0x1ac>
    <c6>   DW_AT_location    : 10 byte block: 3 34 10 60 0 0 0 0 0 9f   (DW_OP_addr: 601034; DW_OP_stack_value)

I don't see how GDB could reconstruct the "&n" in the template, so
that's where my idea falls short.

I'm afraid I know too little about the internals of GDB to
fully appreciate the importance of this problem or have
an idea how it could be handled.

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.

For auto, since it's new, a viable alternative might be to
standardize the debug info format so that eventually all
producers will converge on it. But even that approach won't
help users of existing compilers.

Martin


Simon

[1] https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=shortlog;h=refs/heads/users/simark/template-suffix



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