Differences between revisions 18 and 19
Revision 18 as of 2017-11-07 05:16:51
Size: 3695
Editor: TomTromey
Comment: note some backlinks
Revision 19 as of 2018-07-26 15:39:15
Size: 3719
Editor: TomTromey
Comment: psymtab patch is in
Deletions are marked like this. Additions are marked like this.
Line 18: Line 18:
 * Make partial symbols program-space-independent. [[https://sourceware.org/ml/gdb-patches/2014-02/msg00664.html|Patches here]].  * Make partial symbols program-space-independent. This is partially finished.
Line 20: Line 20:
   * Introduce PSYMBOL_VALUE_ADDRESS, make it have two arguments
   * The psymtab address map must be updated
   * --(Introduce PSYMBOL_VALUE_ADDRESS, make it have two arguments)--
   * --(The psymtab address map must be updated)--
Line 24: Line 24:
     * 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)
     * --(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.)

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. 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!

References

Early discussion on splitting objfiles and on-demand relocation


OngoingWork

None: ObjfileSplitting (last edited 2018-07-26 15:39:15 by TomTromey)

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