From: Tom Tromey <tom@tromey.com>
To: Jan Vrany <jan@vrany.io>
Cc: Tom Tromey <tom@tromey.com>, 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 16:04:12 -0700 [thread overview]
Message-ID: <87fr7hxwcz.fsf@tromey.com> (raw)
In-Reply-To: <1a5011136cd40f89c01b361e18aa8d06b2f60337.camel@vrany.io> (Jan Vrany's message of "Tue, 03 Feb 2026 15:14:43 +0000")
>>>>> "Jan" == Jan Vrany <jan@vrany.io> writes:
Jan> In case the search fails, yes. Otherwise the first implementation that
Jan> finds something wins, the others are not tried. It looks to me this can
Jan> be easily solved by adding each implementation only once.
It depends on which method is called.
For instance linespec generally tries to collect all matches, whereas
type lookups tend to stop with the first (non-stub) type.
Jan> As a side note, when debugging quick symbols I noticed that very often
Jan> the same thing is searched for in quick succession.
Yeah. There's a lot of old & ugly code in there.
There's a cache in symtab.c to try to speed this up.
Jan> In "Python JIT API" series, I allow to add symbols any objfile, even
Jan> the one with existing DWARF. To make this work, I push expanded_symbols_functions
Jan> to the end of qf list. Whether this is a good or bad idea, I do not know - the reason
Jan> for this was to support an arguably extreme usecase where dynamic code is generated
Jan> into statically allocated buffer or section. I'm happy to reintroduce these checks (and
Jan> therefore not supporting this usecase) if it feels "safer".
I didn't look at the series yet but I think this approach will regress
some recent performance improvements.
Tom
prev parent reply other threads:[~2026-02-03 23:05 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
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 [this message]
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=87fr7hxwcz.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