Differences between revisions 15 and 16
Revision 15 as of 2014-07-07 14:48:36
Size: 3652
Editor: TomTromey
Comment: link to another patch
Revision 16 as of 2016-04-12 12:09:37
Size: 3807
Editor: PedroAlves
Comment: add convenience link to early discussion
Deletions are marked like this. Additions are marked like this.
Line 43: Line 43:
= References =

[[https://www.sourceware.org/ml/gdb-patches/2009-06/msg00668.html | Early discussion on splitting objfiles and on-demand relocation]]

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 section_offsets field must be handled somehow. One idea would be to always use the objfile's section offsets and only then apply any psymtab-specific ones

    • 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
    • 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 2016-04-12 12:09:37 by PedroAlves)

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