Right now, gdb's symbol readers add offsets to symbol addresses as the symbols are created. This means that a symbol table is tied to a program space. However, there is no reason that this needs to be so, and the "objfile splitting" project will change this.
The main benefit of this change is that it will be possible to share symbol tables across program spaces. This is a performance gain for some multi-inferior debugging cases. This will also enable sharing of symbol tables within a given program space if dlmopen is used (and is ever supported in gdb). It may also help with fine-grained breakpoint resetting.
This is called "objfile splitting" because the main task is to split struct objfile into program-space-dependent and program-space-independent pieces.
Some parts of this work have already gone in. In particular, struct objfile_per_bfd_storage is the basis of the split: it holds data that was formerly on the objfile, but which is now independent of the program space and attached to the BFD.
- Fix the ELF ifunc cache to put its data into the per-BFD object
- Make partial symbols program-space-independent. This is partially finished.
Introduce PSYMBOL_VALUE_ADDRESS, make it have two arguments
The psymtab address map must be updated
- Psymtabs have a link to the symtab. Either the final switch must wait for full symbols to be fixed, or the change done in parts:
First make partial symbols program-space-independent, adding offsets dynamically
- Perhaps add a macro to choose the obstack for allocation (to make the next step simpler) (There is a patch for this and to remove the backlink.)
- Later, when all the symbols are ready to be migrated, move psymtabs to the per-BFD obstack
- Make full symbols program-space-independent.
symtabs have a backlink to the objfile; this is also used via symbol_objfile and block_objfile
We'll need some form of "bound symbol", so SYMBOL_VALUE_ADDRESS can be given two arguments here.
struct type also has a backlink to the objfile. This must change to point to some other object. It can't be the obstack directly, because we need a way to get the type's arch. It could possibly be the per-BFD after moving gdbarch there. Or, as a temporary measure in order to make the patches incremental, we could introduce a "type allocator" object that holds the necessary data. Note that the strings and other type-related objects, like fields, must be moved at the same time.
Types also have the problem that some types link directly to symbols (see struct cplus_struct_type::template_arguments. This means that either a workaround must be found here, or types cannot fully be shared until symbols are as well. However, changing how type allocation works as a preliminary patch would still be a forward step.
struct objfile_type must be moved to the per-BFD.
linetable holds PCs, so these must be made program-space-independent. Patches here
blocks must also be converted
Put sym_fns into per-BFD storage. This item might be pretty easy, but probably needs to come toward the end. This field may be a good flag to use as a sentinel to determine whether the debuginfo needs to be read or not.
Remove objfile_relocate. Victory!