Re: Decl/def matching with templates without template parameters in the DW_AT_name

[Tom Tromey <tom@tromey.com>]

>>>>> "Simon" == Simon Marchi via Gdb <gdb@sourceware.org> writes:

Simon> Digging in the history leads me to:

Simon>   https://inbox.sourceware.org/gdb-patches/201007302017.41074.pedro@codesourcery.com/

Simon> So RVCT, the RealView compiler.  I don't have access to that,
Simon> unfortunately.  It seems obsolete, also.

I don't like that code.  It calls into type_print from the reader, which
seems very weird.  An approach based on purely traversing the DIE tree
seems preferable to me.

Anyway, making it work again seems possible.  And this time it could
have tests.

The main thing I would want to avoid here is trying to put this extra
name-construction into the indexer.  That will just slow it down -- but
this is normally the most user-visible slow thing in gdb, and most CUs
are of no interest anyway.

The downside of this decision is that expansion may expand too many
CUs.  So for example if there are a million instantiation of template X
and the user types "break X<int>::method", gdb might expand every CU
referencing X and then still only set one breakpoint.

However if this is an issue I think the solution could be to be more
selective at expansion time.  That is, let the user input "X<int>" match
X, but then actually examine the DIE tree to decide if this match should
result in an expansion.

>>> Is it valid DWARF (5) for DW_AT_name of a templated struct instantiation
>>> to omit the template parameters?  I don't see DWARF mandating one or the
>>> other, so I assume that both including them or not are valid.

>> Yeah, this is a case where DWARF is like "here are some tools you
>> could use to express some language features, have at!" and doesn't say
>> "to describe this particular language feature you must use DWARF in
>> this particular way"

Simon> Typical "DWARF is a permissive standard, not a prescriptive one" thing.

For Rust, my view was that a language ought to also have a "binding" to
DWARF, to write down how DWARF features are in fact used by the
language.  DWARF does not really take this view, though, which is why
there are a tags with different names but vaguely similar
meanings... just one of the many ways that DWARF is bad.

Simon> I just found this:
Simon> http://wiki.dwarfstd.org/index.php?title=Best_Practices#Names_of_Program_Entities

This says it "should have a canonical representation" but neglects to
say what that representation should be, so IMO it can't really be relied
upon by debuggers.

It would be a real improvement to debug reading if the canonical form
were in fact reliable across environments -- i.e., proscribed.  gdb
could avoid all name canonicalization during debug reading, which is a
major point of serialization.

This affects other languages as well, for example if Fortran and Ada
specified a canonical case folding... while this would make gdb output
slightly inconsistent with the source, it would also mean we could
perhaps sanely handle some situations that are messy today -- see the
recent discussion of strcasecmp and Unicode.  Though note that DWARF
also neglects to specify a Unicode normalization.

Tom