Re: [PATCH v2 13/13] gdb: update message in symbol_file_add_with_addrs after changes in readnow_functions

["Jan Vraný" <Jan.Vrany@labware.com>]

On Tue, 2025-12-02 at 12:03 -0700, Tom Tromey wrote:
> > > > > > "Jan" == Jan Vraný <Jan.Vrany@labware.com> writes:
> 
> Jan> Maybe better way to go about it might be:
> 
> Jan>  1) introduce new quick functions, say "default_symbol_functions" with
> Jan>     the code from this (V2) series.
> Jan>  2) then DWARF's readnow_functions may inherit from "default_symbol_functions"
> Jan>     and override what's desirable
> 
> Jan> and then JIT reader would just use these new "default_symbol_functions".
> 
> I am not overly fond of the name "default_symbol_functions" but I think
> the general idea holds.

On a second thought, it won't be that easy. One cannot just implement readnow_functions
by merely subclassing "default_symbol_functions" and overriding expand_all_symtabs()
to do what it does right now. 

The problem is that compunit_symtab is not instantiated and installed into an objfile
until call to dw2_instantiate_symtab(). 

So even if one specifies -readnow, more work is done when objfile is loaded, but still CUs are
not instantiated (no call to dw2_instantiate_symtab()). If then corresponding ::search is 
implemented so that it iterates objfile->compunits() then it won't see them. 
This is why commit "gdb: implement readnow_functions::expand_all_symtabs" from this series
calls (new) dw2_instantiate_all_symtabs() from dwarf2_initialize_objfile(). 
And if we do call dw2_instantiate_all_symtabs(), then doing the same thing in expand_all_symtabs
makes no sense. 

In other words: if we want to keep current readnow_functions::expand_all_symtabs() then it would well mean
keeping other methods too and then we may well keep it as it is. 

Still, for JIT reader created objfiles (and for future "Python JIT API"-created ones) we will need
"default_symbol_functions" so we'll end up with "default_symbol_functions" alongside existing 
readnow_functions. I'm fine with that. 

And yes, I do not like name "default_symbol_function" either, I just don't have a better name
right now.

Jan



> 
> Tom