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

[David Blaikie via Gdb <gdb@sourceware.org>]

On Sat, Jan 14, 2023 at 12:28 PM Tom Tromey <tom@tromey.com> wrote:
>
> >>>>> "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.

Agreed. DWARF ends up being more like XML with a library of tags with
suggestions at best, but certainly not "this means this and only this"
& so debuggers/compilers end up with ad-hoc agreements about how
certain features should be encoded. Mostly GCC and GDB get to set that
pseudostandard and Clang/lldb for the most part follow suit, though
some amount of Clang+LLDB do some things together, moreso on MacOS.

I'm always happy to chat more about these things/help set direction on
the Clang side, at least.

>
> 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