From: Tom Tromey <tom@tromey.com>
To: Andrew Burgess <aburgess@redhat.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH] [GDB 18] gdb: resolve class name via DW_AT_signature in cooked index
Date: Fri, 21 Aug 2026 11:07:09 -0600 [thread overview]
Message-ID: <87ik53qu6a.fsf@tromey.com> (raw)
In-Reply-To: <3ea45eb5b7eba98d5b0261a7648720a56fe6d578.1787133721.git.aburgess@redhat.com> (Andrew Burgess's message of "Wed, 19 Aug 2026 11:03:06 +0100")
>>>>> "Andrew" == Andrew Burgess <aburgess@redhat.com> writes:
Andrew> The problem is that the cooked index is unable to determine the name
Andrew> of the parent class `base1` in this case, and so decides not to index
Andrew> any of the member functions.
Andrew> 2. cooked-indexer.c (scan_attributes): Handle DW_AT_signature by
Andrew> looking up the signatured_type via lookup_signatured_type and
Andrew> constructing a section_and_offset origin pointing to the type DIE
Andrew> in the type unit. Restructure the is_declaration / origin-
Andrew> following control flow: change the "else if (origin)" to a
Andrew> standalone "if" so that class declaration stubs marked with
Andrew> IS_TYPE_DECLARATION can still follow their origin to retrieve the
Andrew> class name from the type unit. Add origin.reset() in the other
Andrew> declaration paths to preserve the original behaviour for non-class
Andrew> declarations and Ada imports.
It's been a while since I was deep in the indexer, but looking at
done_reading makes me wonder if this approach is safe:
void
cooked_index_worker_debug_info::done_reading ()
{
/* This has to wait until we read the CUs, we need the list of DWOs. */
process_skeletonless_type_units (m_per_objfile, &m_index_storage);
That is, I think skeletonless type units aren't processed until all
other indexing is done. So if the signatured type appears in one of
these, doesn't this mean the fix will fail?
I don't remember how to set one of these up.
Also my first thought when seeing this patch was that it might not be
thread-safe. I'm still not completely sure. Perhaps it's fine because
other type units seem to be (unfortunately) processed serially.
A typical fix for these kinds of issues is to defer some of the work to
the finalization step in the shard. I guess here the idea would be to
store the signature and the relevant entry in some data structure, then
patch up the parentage or whatever when finalizing.
Tom
next prev parent reply other threads:[~2026-08-21 17:07 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-19 10:03 Andrew Burgess
2026-08-21 17:07 ` Tom Tromey [this message]
2026-08-28 21:30 ` [PATCHv2] " Andrew Burgess
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=87ik53qu6a.fsf@tromey.com \
--to=tom@tromey.com \
--cc=aburgess@redhat.com \
--cc=gdb-patches@sourceware.org \
/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