From: Tom Tromey <tom@tromey.com>
To: Jan Vrany <jan@vrany.io>
Cc: GDB Development <gdb@sourceware.org>
Subject: Re: [RFC PATCH 7/8] gdb/ctf: don't use psymtabs, create symtabs directly
Date: Tue, 03 Feb 2026 07:35:37 -0700 [thread overview]
Message-ID: <87o6m57v46.fsf@tromey.com> (raw)
In-Reply-To: <2e8e28fbfa4894f3f28fe86f698406c4e880753f.camel@vrany.io> (Jan Vrany's message of "Tue, 03 Feb 2026 13:00:23 +0000")
>>>>> "Jan" == Jan Vrany <jan@vrany.io> writes:
>> In order to access the symtabs, elfctf_build_symtabs installs the
>> expanded_symbols_functions quick_symbol_functions implementation, which
>> essentially searches in the existing symtabs. I am pretty sure this is
>> not 100% correct, because this would search unrelated symtabs, if for
>> instance the CTF debug info co-existed with DWARF info. But it's good
>> enough for a prototype.
Jan> True, but does that matter? Should that matter?
If it's possible then it could matter.
Consider if you have both a CTF and a DWARF "readnow" implementation
attached to an objfile. Now all searches are done twice -- probably
won't be incorrect but it will be slower.
In some earlier thread I proposed fixing this by adding a marker to the
compunit_symtab to record where it came from. Then the "expanded
symbols for JIT" expanded-symbols instance could limit its search.
However:
Jan> Also it seems to me that this version does not allow for both CTF and
Jan> DWARF in single objfile:
... do we have any spot any more that records symbols from multiple
readers? Since another option would be to get rid of that ability;
unless we think it'll be used again.
Tom
next parent reply other threads:[~2026-02-03 14:36 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <2e8e28fbfa4894f3f28fe86f698406c4e880753f.camel@vrany.io>
2026-02-03 14:35 ` Tom Tromey [this message]
2026-02-03 15:14 ` Jan Vrany via Gdb
2026-02-03 17:06 ` Simon Marchi via Gdb
2026-02-03 23:05 ` Tom Tromey
2026-02-04 13:24 ` Jan Vrany via Gdb
2026-02-03 23:04 ` Tom Tromey
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=87o6m57v46.fsf@tromey.com \
--to=tom@tromey.com \
--cc=gdb@sourceware.org \
--cc=jan@vrany.io \
/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