Differences between revisions 17 and 18
Revision 17 as of 2017-11-04 20:23:21
Size: 3627
Editor: TomTromey
Comment: per-psymtab section offsets were removed already
Revision 18 as of 2017-11-07 05:16:51
Size: 3695
Editor: TomTromey
Comment: note some backlinks
Deletions are marked like this. Additions are marked like this.
Line 30: Line 30:
   * symtabs have a backlink to the objfile    * symtabs have a backlink to the objfile; this is also used via {{{symbol_objfile}}} and {{{block_objfile}}}

Objfile Splitting

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.

To do

  • Fix the ELF ifunc cache to put its data into the per-BFD object
  • Make partial symbols program-space-independent. Patches here.

    • 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 objfile for allocation (to make the next step simpler)
      • 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!


Early discussion on splitting objfiles and on-demand relocation


None: ObjfileSplitting (last edited 2017-11-07 05:16:51 by TomTromey)

All content (C) 2008 Free Software Foundation. For terms of use, redistribution, and modification, please see the WikiLicense page.