Go forward to Types.
Go backward to Releases.
Go up to Top.

Partial Symbol Tables

   GDB has three types of 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.

   This section describes partial symbol tables.

   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.  (See Symbol Reading.)

   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 types, and enum values declared at file scope.

   The psymtab also contains the range of instruction addresses that the
full symbol table would represent.

   The idea is that there are only two ways for the user (or much of
the code in the debugger) to reference a symbol:

   * 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_function', `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_symbol' does 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

   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.