public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: David Blaikie <dblaikie@gmail.com>
To: Simon Marchi <simark@simark.ca>
Cc: Tom Tromey <tom@tromey.com>, Simon Marchi via Gdb <gdb@sourceware.org>
Subject: Re: Decl/def matching with templates without template parameters in the DW_AT_name
Date: Wed, 18 Jan 2023 14:08:55 -0800	[thread overview]
Message-ID: <CAENS6Eux--9cVmahag--GQMbhD6R0D=g_pZ2O+Aj-=FhDQQXXg@mail.gmail.com> (raw)
In-Reply-To: <4fd385ad-fa48-7fab-0131-d24ae2db45a9@simark.ca>

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.

  reply	other threads:[~2023-01-18 22:09 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-06 17:37 David Blaikie
2023-01-11 18:24 ` Simon Marchi
2023-01-11 23:50   ` David Blaikie
2023-01-12  1:46     ` Simon Marchi
2023-01-14 20:28       ` Tom Tromey
2023-01-16 21:18         ` Simon Marchi
2023-01-18 22:08           ` David Blaikie [this message]
2023-01-18 22:12         ` David Blaikie
2023-01-18 22:01       ` David Blaikie
2023-01-12  2:32     ` Simon Marchi
2023-01-18 22:04       ` David Blaikie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAENS6Eux--9cVmahag--GQMbhD6R0D=g_pZ2O+Aj-=FhDQQXXg@mail.gmail.com' \
    --to=dblaikie@gmail.com \
    --cc=gdb@sourceware.org \
    --cc=simark@simark.ca \
    --cc=tom@tromey.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).