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


Early discussion on splitting objfiles and on-demand relocation


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.