8 Symbol Handling
Symbols are a key part of gdb's operation. Symbols include variables, functions, and types.
Symbol information for a large program can be truly massive, and reading of symbol information is one of the major performance bottlenecks in gdb; it can take many minutes to process it all. Studies have shown that nearly all the time spent is computational, rather than file reading.
One of the ways for gdb to provide a good user experience is to start up quickly, taking no more than a few seconds. It is simply not possible to process all of a program's debugging info in that time, and so we attempt to handle symbols incrementally. For instance, we create partial symbol tables consisting of only selected symbols, and only expand them to full symbol tables when necessary.
8.1 Symbol Reading
gdb reads symbols from symbol files. The usual symbol file is the file containing the program which gdb is debugging. gdb can be directed to use a different file for symbols (with the symbol-file command), and it can also read more symbols via the add-file and load commands. In addition, it may bring in more symbols while loading shared libraries.
Symbol files are initially opened by code in symfile.c using
the BFD library (see Support Libraries). BFD identifies the type
of the file by examining its header.
find_sym_fns then uses
this identification to locate a set of symbol-reading functions.
Symbol-reading modules identify themselves to gdb by calling
add_symtab_fns during their module initialization. The argument
add_symtab_fns is a
struct sym_fns which contains the
name (or name prefix) of the symbol format, the length of the prefix,
and pointers to four functions. These functions are called at various
times to process symbol files whose identification matches the specified
The functions supplied by each module are:
_symfile_init(struct sym_fns *sf)
symbol_file_addwhen we are about to read a new symbol file. This function should clean up any internal state (possibly resulting from half-read previous files, for example) and prepare to read a new symbol file. Note that the symbol file which we are reading might be a new “main” symbol file, or might be a secondary symbol file whose symbols are being added to the existing symbol table.
The argument to xyz
_symfile_initis a newly allocated
bfdfield contains the BFD for the new symbol file being read. Its
privatefield has been zeroed, and can be modified as desired. Typically, a struct of private information will be
malloc'd, and a pointer to it will be placed in the
There is no result from xyz
_symfile_init, but it can call
errorif it detects an unavoidable problem.
symbol_file_addwhen discarding existing symbols. This function needs only handle the symbol-reading module's internal state; the symbol table data structures visible to the rest of gdb will be discarded by
symbol_file_add. It has no arguments and no result. It may be called after xyz
_symfile_init, if a new symbol table is being read, or may be called alone if all symbols are simply being discarded.
_symfile_read(struct sym_fns *sf, CORE_ADDR addr, int mainline)
symbol_file_addto actually read the symbols from a symbol-file into a set of psymtabs or symtabs.
sfpoints to the
struct sym_fnsoriginally passed to xyz
_sym_initfor possible initialization.
addris the offset between the file's specified start address and its true address in memory.
mainlineis 1 if this is the main symbol table being read, and 0 if a secondary symbol file (e.g., shared library or dynamically loaded file) is being read.
In addition, if a symbol-reading module creates psymtabs when
xyz_symfile_read is called, these psymtabs will contain a pointer
to a function xyz
_psymtab_to_symtab, which can be called
from any point in the gdb symbol-handling code.
_psymtab_to_symtab (struct partial_symtab *pst)
PSYMTAB_TO_SYMTABmacro) if the psymtab has not already been read in and had its
pst->symtabpointer set. The argument is the psymtab to be fleshed-out into a symtab. Upon return,
pst->readinshould have been set to 1, and
pst->symtabshould contain a pointer to the new corresponding symtab, or zero if there were no symbols in that part of the symbol file.
8.2 Partial Symbol Tables
- Full symbol tables (symtabs). These contain the main information about symbols and addresses.
- Partial symbol tables (psymtabs). These contain enough information to know when to read the corresponding part of the full symbol table.
- Minimal symbol tables (msymtabs). These contain information gleaned from non-debugging symbols.
A psymtab is constructed by doing a very quick pass over an executable file's debugging information. Small amounts of information are extracted—enough to identify which parts of the symbol table will need to be re-read and fully digested later, when the user needs the information. The speed of this pass causes gdb to start up very quickly. Later, as the detailed rereading occurs, it occurs in small pieces, at various times, and the delay therefrom is mostly invisible to the user.
The symbols that show up in a file's psymtab should be, roughly, those
visible to the debugger's user when the program is not running code from
that file. These include external symbols and types, static symbols and
enum values declared at file scope.
The psymtab also contains the range of instruction addresses that the full symbol table would represent.
- By its address (e.g., execution stops at some address which is inside a
function in this file). The address will be noticed to be in the
range of this psymtab, and the full symtab will be read in.
find_pc_line, and other
find_pc_...functions handle this.
- By its name
(e.g., the user asks to print a variable, or set a breakpoint on a
function). Global names and file-scope names will be found in the
psymtab, which will cause the symtab to be pulled in. Local names will
have to be qualified by a global name, or a file-scope name, in which
case we will have already read in the symtab as we evaluated the
qualifier. Or, a local symbol can be referenced when we are “in” a
local scope, in which case the first case applies.
lookup_symboldoes most of the work here.
The only reason that psymtabs exist is to cause a symtab to be read in at the right moment. Any symbol that can be elided from a psymtab, while still causing that to happen, should not appear in it. Since psymtabs don't have the idea of scope, you can't put local symbols in them anyway. Psymtabs don't have the idea of the type of a symbol, either, so types need not appear, unless they will be referenced by name.
It is a bug for gdb to behave one way when only a psymtab has been read, and another way if the corresponding symtab has been read in. Such bugs are typically caused by a psymtab that does not contain all the visible symbols, or which has the wrong instruction address ranges.
The psymtab for a particular section of a symbol file (objfile) could be thrown away after the symtab has been read in. The symtab should always be searched before the psymtab, so the psymtab will never be used (in a bug-free environment). Currently, psymtabs are allocated on an obstack, and all the psymbols themselves are allocated in a pair of large arrays on an obstack, so there is little to be gained by trying to free them unless you want to do a lot more work.
Whether or not psymtabs are created depends on the objfile's symbol reader. The core of gdb hides the details of partial symbols and partial symbol tables behind a set of function pointers known as the quick symbol functions. These are documented in symfile.h.
Fundamental Types (e.g.,
These are the fundamental types that gdb uses internally. Fundamental types from the various debugging formats (stabs, ELF, etc) are mapped into one of these. They are basically a union of all fundamental types that gdb knows about for all the languages that gdb knows about.
Type Codes (e.g.,
Each time gdb builds an internal type, it marks it with one
of these types. The type may be a fundamental type, such as
TYPE_CODE_INT, or a derived type, such as
which is a pointer to another type. Typically, several
types map to one
TYPE_CODE_* type, and are distinguished by
other members of the type struct, such as whether the type is signed
or unsigned, and how many bits it uses.
Builtin Types (e.g.,
These are instances of type structs that roughly correspond to
fundamental types and are created as global types for gdb to
use for various ugly historical reasons. We eventually want to
eliminate these. Note for example that
initialized in gdbtypes.c is basically the same as a
TYPE_CODE_INT type that is initialized in c-lang.c for
FT_INTEGER fundamental type. The difference is that the
builtin_type is not associated with any particular objfile, and
only one instance exists, while c-lang.c builds as many
TYPE_CODE_INT types as needed, with each one associated with
some particular objfile.
8.4 Object File Formats
a.out format is so simple that it doesn't have any reserved
place for debugging information. (Hey, the original Unix hackers used
adb, which is a machine-language debugger!) The only debugging
a.out is stabs, which is encoded as a set of normal
symbols with distinctive attributes.
a.out reader is in dbxread.c.
The COFF specification includes support for debugging. Although this was a step forward, the debugging information was woefully limited. For instance, it was not possible to represent code that came from an included file. GNU's COFF-using configs often use stabs-type info, encapsulated in special sections.
The COFF reader is in coffread.c.
The basic ECOFF reader is in mipsread.c.
The IBM RS/6000 running AIX uses an object file format called XCOFF.
The COFF sections, symbols, and line numbers are used, but debugging
dbx-style stabs whose strings are located in the
.debug section (rather than the string table). For more
information, see Top (The Stabs Debugging Format).
The shared library scheme has a clean interface for figuring out what shared libraries are in use, but the catch is that everything which refers to addresses (symbol tables and breakpoints at least) needs to be relocated for both shared libraries and the main executable. At least using the standard mechanism this can only be done once the program has been run (or the core file has been read).
While BFD includes special PE support, gdb needs only the basic COFF reader.
The ELF format came with System V Release 4 (SVR4) Unix. ELF is similar to COFF in being organized into a number of sections, but it removes many of COFF's limitations. Debugging info may be either stabs encapsulated in ELF sections, or more commonly these days, DWARF.
The basic ELF reader is in elfread.c.
The SOM reader is in somread.c.
8.5 Debugging File Formats
This section describes characteristics of debugging information that are independent of the object file format.
While dbxread.c does some of the basic stab processing, including for encapsulated versions, stabsread.c does the real work.
8.5.3 Mips debug (Third Eye)
The file mdebugread.c implements reading for this format.
8.5.4 DWARF 2
The DWARF 2 reader is in dwarf2read.c.
8.5.5 Compressed DWARF 2
Compressed DWARF 2 is not technically a separate debugging format, but
merely DWARF 2 debug information that has been compressed. In this
format, every object-file section holding DWARF 2 debugging
information is compressed and prepended with a header. (The section
is also typically renamed, so a section called
.debug_info in a
DWARF 2 binary would be called
.zdebug_info in a compressed
DWARF 2 binary.) The header is 12 bytes long:
- 4 bytes: the literal string “ZLIB”
- 8 bytes: the uncompressed size of the section, in big-endian byte order.
The same reader is used for both compressed an normal DWARF 2 info.
Section decompression is done in
8.5.6 DWARF 3
8.6 Adding a New Symbol Reader to gdb
If you need to add a new object file format, you must first add it to BFD. This is beyond the scope of this document.
You must then arrange for the BFD code to provide access to the debugging symbols. Generally gdb will have to call swapping routines from BFD and a few other BFD internal routines to locate the debugging information. As much as possible, gdb should not depend on the BFD internal data structures.
For some targets (e.g., COFF), there is a special transfer vector used to call swapping routines, since the external data structures on various platforms have different sizes and layouts. Specialized routines that will only ever be implemented by one object file format may be called directly. This interface should be described in a file bfd/libxyz.h, which is included by gdb.
8.7 Memory Management for Symbol Files
Most memory associated with a loaded symbol file is stored on
objfile_obstack. This includes symbols, types,
namespace data, and other information produced by the symbol readers.
Because this data lives on the objfile's obstack, it is automatically released when the objfile is unloaded or reloaded. Therefore one objfile must not reference symbol or type data from another objfile; they could be unloaded at different times.
User convenience variables, et cetera, have associated types. Normally these types live in the associated objfile. However, when the objfile is unloaded, those types are deep copied to global memory, so that the values of the user variables and history items are not lost.