Support Libraries

Go forward to Coding
Go backward to Native Debugging
Go up to Top
Go to the top op gdbint

Support Libraries


BFD provides support for GDB in several ways:
_identifying executable and core files_
     BFD will identify a variety of file types, including a.out, coff,
     and several variants thereof, as well as several kinds of core
_access to sections of files_
     BFD parses the file headers to determine the names, virtual
     addresses, sizes, and file locations of all the various named
     sections in files (such as the text section or the data section).
     GDB simply calls BFD to read or write section X at byte offset Y
     for length Z.
_specialized core file support_
     BFD provides routines to determine the failing command name stored
     in a core file, the signal with which the program failed, and
     whether a core file matches (i.e. could be a core dump of) a
     particular executable file.
_locating the symbol information_
     GDB uses an internal interface of BFD to determine where to find
     the symbol information in an executable file or symbol-file.  GDB
     itself handles the reading of symbols, since BFD does not
     "understand" debug symbols, but GDB uses BFD's cached information
     to find the symbols, string table, etc.


The opcodes library provides GDB's disassembler.  (It's a separate
library because it's also used in binutils, for `objdump').




The `libiberty' library provides a set of functions and features that
integrate and improve on functionality found in modern operating
systems.  Broadly speaking, such features can be divided into three
groups: supplemental functions (functions that may be missing in some
environments and operating systems), replacement functions (providing a
uniform and easier to use interface for commonly used standard
functions), and extensions (which provide additional functionality
beyond standard functions).
   GDB uses various features provided by the `libiberty' library, for
instance the C++ demangler, the IEEE floating format support functions,
the input options parser `getopt', the `obstack' extension, and other

`obstacks' in GDB

The obstack mechanism provides a convenient way to allocate and free
chunks of memory.  Each obstack is a pool of memory that is managed
like a stack.  Objects (of any nature, size and alignment) are
allocated and freed in a LIFO fashion on an obstack (see `libiberty''s
documenatation for a more detailed explanation of `obstacks').
   The most noticeable use of the `obstacks' in GDB is in object files.
There is an obstack associated with each internal representation of an
object file.  Lots of things get allocated on these `obstacks':
dictionary entries, blocks, blockvectors, symbols, minimal symbols,
types, vectors of fundamental types, class fields of types, object
files section lists, object files section offets lists, line tables,
symbol tables, partial symbol tables, string tables, symbol table
private data, macros tables, debug information sections and entries,
import and export lists (som), unwind information (hppa), dwarf2
location expressions data.  Plus various strings such as directory
names strings, debug format strings, names of types.
   An essential and convenient property of all data on `obstacks' is
that memory for it gets allocated (with `obstack_alloc') at various
times during a debugging sesssion, but it is released all at once using
the `obstack_free' function.  The `obstack_free' function takes a
pointer to where in the stack it must start the deletion from (much
like the cleanup chains have a pointer to where to start the cleanups).
Because of the stack like structure of the `obstacks', this allows to
free only a top portion of the obstack.  There are a few instances in
GDB where such thing happens.  Calls to `obstack_free' are done after
some local data is allocated to the obstack.  Only the local data is
deleted from the obstack.  Of course this assumes that nothing between
the `obstack_alloc' and the `obstack_free' allocates anything else on
the same obstack.  For this reason it is best and safest to use
temporary `obstacks'.
   Releasing the whole obstack is also not safe per se.  It is safe only
under the condition that we know the `obstacks' memory is no longer
needed.  In GDB we get rid of the `obstacks' only when we get rid of
the whole objfile(s), for instance upon reading a new symbol file.


Regex conditionals.