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

David Blaikie dblaikie@gmail.com
Wed Jan 18 22:08:55 GMT 2023


On Mon, Jan 16, 2023 at 1:18 PM Simon Marchi <simark@simark.ca> wrote:
>
> > 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.
>
> This is my understanding of what you are saying.  Save the name without
> the template part in the cooked index, but attach to it a data structure
> that describes the template parameters.  When the user types, let's say,
> "b my_class<int, 2>::my_method", "my_class<int, 2>" gets translated to
> the name "my_class" plus a description of the concrete arguments (the
> type argument "int" and the value argument 2).  Then, when checking if a
> given CU should expanded, and we have a match for the "my_class" name,
> we compare the data structures describing the parameters to the one
> describing the arguments, see if it's really a match.  Does that sound
> right?

That's more or less what we did in lldb - though we do do both lookups
(try "t1<int>" because that's what we have on hand (need to be able to
create that from the DIEs to show something good to the user anyway)
and if that doesn't find any results, try "t1" then filter out the
results looking for the equivalent of "t1<int>" based on the DIEs/some
processed data structure from the DIEs).

It'd be really good/important for us to all agree on what goes in the
index so that .debug_names can be effectively portable. I think the
goal should be that if the template has a simplified DW_AT_name, then
the index entry should be similarly simplified (that's what Clang does
for now, at least & what the DWARF spec says to do, I think/assume
(even if it doesn't speak about template naming)).

> I'm just a bit worried that it might be difficult to implement this "is
> there a match function", given the complex rules of C++ template
> deduction.  But maybe it's not so bad, or we already have that logic
> somewhere.

Yeah, in lldb I think we're doing that based on the string we would
use to show to a user - which in lldb's case is from Clang's AST
generated from DWARF DIEs, but it doesn't matter too much how you do
it, as you say, there's already some logic to do that in the debugger
to show users a name string - so check that between instantiations to
check they're the same entity.


More information about the Gdb mailing list