Re: [RFC PATCH 7/8] gdb/ctf: don't use psymtabs, create symtabs directly

[Jan Vrany via Gdb <gdb@sourceware.org>]

On Tue, 2026-02-03 at 07:35 -0700, Tom Tromey wrote:
> > > > > > "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 case the search fails, yes. Otherwise the first implementation that
finds something wins, the others are not tried. It looks to me this can
be easily solved by adding each implementation only once.

As a side note, when debugging quick symbols I noticed that very often
the same thing is searched for in quick succession. 

> 
> 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.

In "Python JIT API" series, I allow to add symbols any objfile, even
the one with existing DWARF. To make this work, I push expanded_symbols_functions
to the end of qf list. Whether this is a good or bad idea, I do not know - the reason 
for this was to support an arguably extreme usecase where dynamic code is generated 
into statically allocated buffer or section. I'm happy to reintroduce these checks (and
therefore not supporting this usecase) if it feels "safer".

Jan

> 
> Tom