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