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

Jan Vrany via Gdb <[email protected]> Wed, 04 Feb 2026 13:24:40 +0000
Newsgroups gmane.comp.gdb.devel
Message-ID <[email protected]>
On Tue, 2026-02-03 at 16:05 -0700, Tom Tromey wrote:
> > > > > > "Simon" == Simon Marchi <[email protected]> writes:
> 
> Simon> I think it would be safer for each quick_symbol_functions to search its
> Simon> own stuff only.  What I'm thinking is that the
> Simon> expanded_symbols_functions can hold a vector<compunit_symtab *>,
> Simon> containing the compunit_symtabs created by this reader.  The search
> Simon> method of expanded_symbols_functions would search those compunits.  If
> Simon> you have both the JIT reader and the CTF reader active, then they would
> Simon> both push there own expanded_symbols_functions instance, with their own
> Simon> list of compunit_symtabs.
> 
> This would be totally fine and might help us get rid of the last things
> that iterate over all compunits.  Aside from genuine needs -- "maint"
> commands and relocation -- I tend to think this should not be done.
> 
Okay, it seems that there's an agreement this is the way to go. 

UUIC this means that:
1) there can be multiple compunit_symtabs for the same code
   (say you have both CTF and DWARF debug info so each will have its 
   own compunit_symtab with its own, possibly different, symbols). 
2) Given a compunit_symtab, it can only contain data from one reader.
   In another words, (Python) JIT reader may not be able to add symbols
   to compunit_symtab created by DWARF reader. 

Jan