gdbint.info: Support Libraries
Go forward to Coding
Go backward to Native Debugging
Go up to Top
Go to the top op gdbint
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
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.
Created Mon Nov 8 17:42:45 2004 on tillpc with info_to_html version 0.9.6.