Subversion Repositories or1k_old

This is gdbint.info, produced by makeinfo version 4.1 from
./gdbint.texinfo.

INFO-DIR-SECTION Programming & development tools.
START-INFO-DIR-ENTRY
* Gdb-Internals: (gdbint).      The GNU debugger's internals.
END-INFO-DIR-ENTRY

   This file documents the internals of the GNU debugger GDB.
Copyright 1990,1991,1992,1993,1994,1996,1998,1999,2000,2001,2002
Free Software Foundation, Inc.  Contributed by Cygnus Solutions.
Written by John Gilmore.  Second Edition by Stan Shebs.

   Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.1 or
any later version published by the Free Software Foundation; with no
Invariant Sections, with the Front-Cover Texts being "A GNU Manual,"
and with the Back-Cover Texts as in (a) below.

   (a) The FSF's Back-Cover Text is: "You have freedom to copy and
modify this GNU Manual, like GNU software.  Copies published by the Free
Software Foundation raise funds for GNU development."


File: gdbint.info,  Node: libgdb,  Next: Symbol Handling,  Prev: User Interface,  Up: Top

libgdb
******

libgdb 1.0
==========

   `libgdb' 1.0 was an abortive project of years ago.  The theory was
to provide an API to GDB's functionality.

libgdb 2.0
==========

   `libgdb' 2.0 is an ongoing effort to update GDB so that is better
able to support graphical and other environments.

   Since `libgdb' development is on-going, its architecture is still
evolving.  The following components have so far been identified:

   * Observer - `gdb-events.h'.

   * Builder - `ui-out.h'

   * Event Loop - `event-loop.h'

   * Library - `gdb.h'

   The model that ties these components together is described below.

The `libgdb' Model
==================

   A client of `libgdb' interacts with the library in two ways.

   * As an observer (using `gdb-events') receiving notifications from
     `libgdb' of any internal state changes (break point changes, run
     state, etc).

   * As a client querying `libgdb' (using the `ui-out' builder) to
     obtain various status values from GDB.

   Since `libgdb' could have multiple clients (e.g. a GUI supporting
the existing GDB CLI), those clients must co-operate when controlling
`libgdb'.  In particular, a client must ensure that `libgdb' is idle
(i.e. no other client is using `libgdb') before responding to a
`gdb-event' by making a query.

CLI support
===========

   At present GDB's CLI is very much entangled in with the core of
`libgdb'.  Consequently, a client wishing to include the CLI in their
interface needs to carefully co-ordinate its own and the CLI's
requirements.

   It is suggested that the client set `libgdb' up to be bi-modal
(alternate between CLI and client query modes).  The notes below sketch
out the theory:

   * The client registers itself as an observer of `libgdb'.

   * The client create and install `cli-out' builder using its own
     versions of the `ui-file' `gdb_stderr', `gdb_stdtarg' and
     `gdb_stdout' streams.

   * The client creates a separate custom `ui-out' builder that is only
     used while making direct queries to `libgdb'.

   When the client receives input intended for the CLI, it simply
passes it along.  Since the `cli-out' builder is installed by default,
all the CLI output in response to that command is routed (pronounced
rooted) through to the client controlled `gdb_stdout' et. al. streams.
At the same time, the client is kept abreast of internal changes by
virtue of being a `libgdb' observer.

   The only restriction on the client is that it must wait until
`libgdb' becomes idle before initiating any queries (using the client's
custom builder).

`libgdb' components
===================

Observer - `gdb-events.h'
-------------------------

   `gdb-events' provides the client with a very raw mechanism that can
be used to implement an observer.  At present it only allows for one
observer and that observer must, internally, handle the need to delay
the processing of any event notifications until after `libgdb' has
finished the current command.

Builder - `ui-out.h'
--------------------

   `ui-out' provides the infrastructure necessary for a client to
create a builder.  That builder is then passed down to `libgdb' when
doing any queries.

Event Loop - `event-loop.h'
---------------------------

   `event-loop', currently non-re-entrant, provides a simple event
loop.  A client would need to either plug its self into this loop or,
implement a new event-loop that GDB would use.

   The event-loop will eventually be made re-entrant.  This is so that
{No value for `GDB'} can better handle the problem of some commands
blocking instead of returning.

Library - `gdb.h'
-----------------

   `libgdb' is the most obvious component of this system.  It provides
the query interface.  Each function is parameterized by a `ui-out'
builder.  The result of the query is constructed using that builder
before the query function returns.


File: gdbint.info,  Node: Symbol Handling,  Next: Language Support,  Prev: libgdb,  Up: Top

Symbol Handling
***************

   Symbols are a key part of GDB's operation.  Symbols include
variables, functions, and types.

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, or while reading symbols from shared libraries.

   Symbol files are initially opened by code in `symfile.c' using the
BFD library (*note 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 to
`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 prefix.

   The functions supplied by each module are:

`XYZ_symfile_init(struct sym_fns *sf)'
     Called from `symbol_file_add' when 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_init' is a newly allocated `struct
     sym_fns' whose `bfd' field contains the BFD for the new symbol
     file being read.  Its `private' field 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
     `private' field.

     There is no result from `XYZ_symfile_init', but it can call
     `error' if it detects an unavoidable problem.

`XYZ_new_init()'
     Called from `symbol_file_add' when 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.

`XYZ_symfile_read(struct sym_fns *sf, CORE_ADDR addr, int mainline)'
     Called from `symbol_file_add' to actually read the symbols from a
     symbol-file into a set of psymtabs or symtabs.

     `sf' points to the `struct sym_fns' originally passed to
     `XYZ_sym_init' for possible initialization.  `addr' is the offset
     between the file's specified start address and its true address in
     memory.  `mainline' is 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.

`XYZ_psymtab_to_symtab (struct partial_symtab *pst)'
     Called from `psymtab_to_symtab' (or the `PSYMTAB_TO_SYMTAB' macro)
     if the psymtab has not already been read in and had its
     `pst->symtab' pointer set.  The argument is the psymtab to be
     fleshed-out into a symtab.  Upon return, `pst->readin' should have
     been set to 1, and `pst->symtab' should contain a pointer to the
     new corresponding symtab, or zero if there were no symbols in that
     part of the symbol file.

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.

   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
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.

Types
=====

Fundamental Types (e.g., `FT_VOID', `FT_BOOLEAN').
--------------------------------------------------

   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., `TYPE_CODE_PTR', `TYPE_CODE_ARRAY').
------------------------------------------------------

   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 `TYPE_CODE_PTR' which is a pointer to another
type.  Typically, several `FT_*' 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., `builtin_type_void', `builtin_type_char').
---------------------------------------------------------------

   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 `builtin_type_int' initialized in
`gdbtypes.c' is basically the same as a `TYPE_CODE_INT' type that is
initialized in `c-lang.c' for an `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.

Object File Formats
===================

a.out
-----

   The `a.out' format is the original file format for Unix.  It
consists of three sections: `text', `data', and `bss', which are for
program code, initialized data, and uninitialized data, respectively.

   The `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
format for `a.out' is stabs, which is encoded as a set of normal
symbols with distinctive attributes.

   The basic `a.out' reader is in `dbxread.c'.

COFF
----

   The COFF format was introduced with System V Release 3 (SVR3) Unix.
COFF files may have multiple sections, each prefixed by a header.  The
number of sections is limited.

   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.

   The COFF reader is in `coffread.c'.

ECOFF
-----

   ECOFF is an extended COFF originally introduced for Mips and Alpha
workstations.

   The basic ECOFF reader is in `mipsread.c'.

XCOFF
-----

   The IBM RS/6000 running AIX uses an object file format called XCOFF.
The COFF sections, symbols, and line numbers are used, but debugging
symbols are `dbx'-style stabs whose strings are located in the `.debug'
section (rather than the string table).  For more information, see
*Note Top: (stabs)Top.

   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).

PE
--

   Windows 95 and NT use the PE ("Portable Executable") format for their
executables.  PE is basically COFF with additional headers.

   While BFD includes special PE support, GDB needs only the basic COFF
reader.

ELF
---

   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.

   The basic ELF reader is in `elfread.c'.

SOM
---

   SOM is HP's object file and debug format (not to be confused with
IBM's SOM, which is a cross-language ABI).

   The SOM reader is in `hpread.c'.

Other File Formats
------------------

   Other file formats that have been supported by GDB include Netware
Loadable Modules (`nlmread.c').

Debugging File Formats
======================

   This section describes characteristics of debugging information that
are independent of the object file format.

stabs
-----

   `stabs' started out as special symbols within the `a.out' format.
Since then, it has been encapsulated into other file formats, such as
COFF and ELF.

   While `dbxread.c' does some of the basic stab processing, including
for encapsulated versions, `stabsread.c' does the real work.

COFF
----

   The basic COFF definition includes debugging information.  The level
of support is minimal and non-extensible, and is not often used.

Mips debug (Third Eye)
----------------------

   ECOFF includes a definition of a special debug format.

   The file `mdebugread.c' implements reading for this format.

DWARF 1
-------

   DWARF 1 is a debugging format that was originally designed to be
used with ELF in SVR4 systems.

   The DWARF 1 reader is in `dwarfread.c'.

DWARF 2
-------

   DWARF 2 is an improved but incompatible version of DWARF 1.

   The DWARF 2 reader is in `dwarf2read.c'.

SOM
---

   Like COFF, the SOM definition includes debugging information.

Adding a New Symbol Reader to GDB
=================================

   If you are using an existing object file format (`a.out', COFF, ELF,
etc), there is probably little to be done.

   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.


File: gdbint.info,  Node: Language Support,  Next: Host Definition,  Prev: Symbol Handling,  Up: Top

Language Support
****************

   GDB's language support is mainly driven by the symbol reader,
although it is possible for the user to set the source language
manually.

   GDB chooses the source language by looking at the extension of the
file recorded in the debug info; `.c' means C, `.f' means Fortran, etc.
It may also use a special-purpose language identifier if the debug
format supports it, like with DWARF.

Adding a Source Language to GDB
===============================

   To add other languages to GDB's expression parser, follow the
following steps:

_Create the expression parser._
     This should reside in a file `LANG-exp.y'.  Routines for building
     parsed expressions into a `union exp_element' list are in
     `parse.c'.

     Since we can't depend upon everyone having Bison, and YACC produces
     parsers that define a bunch of global names, the following lines
     *must* be included at the top of the YACC parser, to prevent the
     various parsers from defining the same global names:

          #define yyparse         LANG_parse
          #define yylex           LANG_lex
          #define yyerror         LANG_error
          #define yylval          LANG_lval
          #define yychar          LANG_char
          #define yydebug         LANG_debug
          #define yypact          LANG_pact
          #define yyr1            LANG_r1
          #define yyr2            LANG_r2
          #define yydef           LANG_def
          #define yychk           LANG_chk
          #define yypgo           LANG_pgo
          #define yyact           LANG_act
          #define yyexca          LANG_exca
          #define yyerrflag       LANG_errflag
          #define yynerrs         LANG_nerrs

     At the bottom of your parser, define a `struct language_defn' and
     initialize it with the right values for your language.  Define an
     `initialize_LANG' routine and have it call
     `add_language(LANG_language_defn)' to tell the rest of GDB that
     your language exists.  You'll need some other supporting variables
     and functions, which will be used via pointers from your
     `LANG_language_defn'.  See the declaration of `struct
     language_defn' in `language.h', and the other `*-exp.y' files, for
     more information.

_Add any evaluation routines, if necessary_
     If you need new opcodes (that represent the operations of the
     language), add them to the enumerated type in `expression.h'.  Add
     support code for these operations in the `evaluate_subexp' function
     defined in the file `eval.c'.  Add cases for new opcodes in two
     functions from `parse.c': `prefixify_subexp' and
     `length_of_subexp'.  These compute the number of `exp_element's
     that a given operation takes up.

_Update some existing code_
     Add an enumerated identifier for your language to the enumerated
     type `enum language' in `defs.h'.

     Update the routines in `language.c' so your language is included.
     These routines include type predicates and such, which (in some
     cases) are language dependent.  If your language does not appear
     in the switch statement, an error is reported.

     Also included in `language.c' is the code that updates the variable
     `current_language', and the routines that translate the
     `language_LANG' enumerated identifier into a printable string.

     Update the function `_initialize_language' to include your
     language.  This function picks the default language upon startup,
     so is dependent upon which languages that GDB is built for.

     Update `allocate_symtab' in `symfile.c' and/or symbol-reading code
     so that the language of each symtab (source file) is set properly.
     This is used to determine the language to use at each stack frame
     level.  Currently, the language is set based upon the extension of
     the source file.  If the language can be better inferred from the
     symbol information, please set the language of the symtab in the
     symbol-reading code.

     Add helper code to `print_subexp' (in `expprint.c') to handle any
     new expression opcodes you have added to `expression.h'.  Also,
     add the printed representations of your operators to
     `op_print_tab'.

_Add a place of call_
     Add a call to `LANG_parse()' and `LANG_error' in `parse_exp_1'
     (defined in `parse.c').

_Use macros to trim code_
     The user has the option of building GDB for some or all of the
     languages.  If the user decides to build GDB for the language
     LANG, then every file dependent on `language.h' will have the
     macro `_LANG_LANG' defined in it.  Use `#ifdef's to leave out
     large routines that the user won't need if he or she is not using
     your language.

     Note that you do not need to do this in your YACC parser, since if
     GDB is not build for LANG, then `LANG-exp.tab.o' (the compiled
     form of your parser) is not linked into GDB at all.

     See the file `configure.in' for how GDB is configured for
     different languages.

_Edit `Makefile.in'_
     Add dependencies in `Makefile.in'.  Make sure you update the macro
     variables such as `HFILES' and `OBJS', otherwise your code may not
     get linked in, or, worse yet, it may not get `tar'red into the
     distribution!


File: gdbint.info,  Node: Host Definition,  Next: Target Architecture Definition,  Prev: Language Support,  Up: Top

Host Definition
***************

   With the advent of Autoconf, it's rarely necessary to have host
definition machinery anymore.  The following information is provided,
mainly, as an historical reference.

Adding a New Host
=================

   GDB's host configuration support normally happens via Autoconf.  New
host-specific definitions should not be needed.  Older hosts GDB still
use the host-specific definitions and files listed below, but these
mostly exist for historical reasons, and will eventually disappear.

`gdb/config/ARCH/XYZ.mh'
     This file once contained both host and native configuration
     information (*note Native Debugging::) for the machine XYZ.  The
     host configuration information is now handed by Autoconf.

     Host configuration information included a definition of
     `XM_FILE=xm-XYZ.h' and possibly definitions for `CC',
     `SYSV_DEFINE', `XM_CFLAGS', `XM_ADD_FILES', `XM_CLIBS',
     `XM_CDEPS', etc.; see `Makefile.in'.

     New host only configurations do not need this file.

`gdb/config/ARCH/xm-XYZ.h'
     This file once contained definitions and includes required when
     hosting gdb on machine XYZ.  Those definitions and includes are now
     handled by Autoconf.

     New host and native configurations do not need this file.

     _Maintainer's note: Some hosts continue to use the `xm-xyz.h' file
     to define the macros HOST_FLOAT_FORMAT, HOST_DOUBLE_FORMAT and
     HOST_LONG_DOUBLE_FORMAT.  That code also needs to be replaced with
     either an Autoconf or run-time test._

Generic Host Support Files
--------------------------

   There are some "generic" versions of routines that can be used by
various systems.  These can be customized in various ways by macros
defined in your `xm-XYZ.h' file.  If these routines work for the XYZ
host, you can just include the generic file's name (with `.o', not
`.c') in `XDEPFILES'.

   Otherwise, if your machine needs custom support routines, you will
need to write routines that perform the same functions as the generic
file.  Put them into `XYZ-xdep.c', and put `XYZ-xdep.o' into
`XDEPFILES'.

`ser-unix.c'
     This contains serial line support for Unix systems.  This is always
     included, via the makefile variable `SER_HARDWIRE'; override this
     variable in the `.mh' file to avoid it.

`ser-go32.c'
     This contains serial line support for 32-bit programs running
     under DOS, using the DJGPP (a.k.a. GO32) execution environment.

`ser-tcp.c'
     This contains generic TCP support using sockets.

Host Conditionals
=================

   When GDB is configured and compiled, various macros are defined or
left undefined, to control compilation based on the attributes of the
host system.  These macros and their meanings (or if the meaning is not
documented here, then one of the source files where they are used is
indicated) are:

`GDBINIT_FILENAME'
     The default name of GDB's initialization file (normally
     `.gdbinit').

`NO_STD_REGS'
     This macro is deprecated.

`NO_SYS_FILE'
     Define this if your system does not have a `<sys/file.h>'.

`SIGWINCH_HANDLER'
     If your host defines `SIGWINCH', you can define this to be the name
     of a function to be called if `SIGWINCH' is received.

`SIGWINCH_HANDLER_BODY'
     Define this to expand into code that will define the function
     named by the expansion of `SIGWINCH_HANDLER'.

`ALIGN_STACK_ON_STARTUP'
     Define this if your system is of a sort that will crash in
     `tgetent' if the stack happens not to be longword-aligned when
     `main' is called.  This is a rare situation, but is known to occur
     on several different types of systems.

`CRLF_SOURCE_FILES'
     Define this if host files use `\r\n' rather than `\n' as a line
     terminator.  This will cause source file listings to omit `\r'
     characters when printing and it will allow `\r\n' line endings of
     files which are "sourced" by gdb.  It must be possible to open
     files in binary mode using `O_BINARY' or, for fopen, `"rb"'.

`DEFAULT_PROMPT'
     The default value of the prompt string (normally `"(gdb) "').

`DEV_TTY'
     The name of the generic TTY device, defaults to `"/dev/tty"'.

`FCLOSE_PROVIDED'
     Define this if the system declares `fclose' in the headers included
     in `defs.h'.  This isn't needed unless your compiler is unusually
     anal.

`FOPEN_RB'
     Define this if binary files are opened the same way as text files.

`GETENV_PROVIDED'
     Define this if the system declares `getenv' in its headers included
     in `defs.h'.  This isn't needed unless your compiler is unusually
     anal.

`HAVE_MMAP'
     In some cases, use the system call `mmap' for reading symbol
     tables.  For some machines this allows for sharing and quick
     updates.

`HAVE_TERMIO'
     Define this if the host system has `termio.h'.

`INT_MAX'
`INT_MIN'
`LONG_MAX'
`UINT_MAX'
`ULONG_MAX'
     Values for host-side constants.

`ISATTY'
     Substitute for isatty, if not available.

`LONGEST'
     This is the longest integer type available on the host.  If not
     defined, it will default to `long long' or `long', depending on
     `CC_HAS_LONG_LONG'.

`CC_HAS_LONG_LONG'
     Define this if the host C compiler supports `long long'.  This is
     set by the `configure' script.

`PRINTF_HAS_LONG_LONG'
     Define this if the host can handle printing of long long integers
     via the printf format conversion specifier `ll'.  This is set by
     the `configure' script.

`HAVE_LONG_DOUBLE'
     Define this if the host C compiler supports `long double'.  This is
     set by the `configure' script.

`PRINTF_HAS_LONG_DOUBLE'
     Define this if the host can handle printing of long double
     float-point numbers via the printf format conversion specifier
     `Lg'.  This is set by the `configure' script.

`SCANF_HAS_LONG_DOUBLE'
     Define this if the host can handle the parsing of long double
     float-point numbers via the scanf format conversion specifier
     `Lg'.  This is set by the `configure' script.

`LSEEK_NOT_LINEAR'
     Define this if `lseek (n)' does not necessarily move to byte number
     `n' in the file.  This is only used when reading source files.  It
     is normally faster to define `CRLF_SOURCE_FILES' when possible.

`L_SET'
     This macro is used as the argument to `lseek' (or, most commonly,
     `bfd_seek').  FIXME, should be replaced by SEEK_SET instead, which
     is the POSIX equivalent.

`MMAP_BASE_ADDRESS'
     When using HAVE_MMAP, the first mapping should go at this address.

`MMAP_INCREMENT'
     when using HAVE_MMAP, this is the increment between mappings.

`NORETURN'
     If defined, this should be one or more tokens, such as `volatile',
     that can be used in both the declaration and definition of
     functions to indicate that they never return.  The default is
     already set correctly if compiling with GCC.  This will almost
     never need to be defined.

`ATTR_NORETURN'
     If defined, this should be one or more tokens, such as
     `__attribute__ ((noreturn))', that can be used in the declarations
     of functions to indicate that they never return.  The default is
     already set correctly if compiling with GCC.  This will almost
     never need to be defined.

`USE_GENERIC_DUMMY_FRAMES'
     Define this to 1 if the target is using the generic inferior
     function call code.  See `blockframe.c' for more information.

`USE_MMALLOC'
     GDB will use the `mmalloc' library for memory allocation for
     symbol reading if this symbol is defined.  Be careful defining it
     since there are systems on which `mmalloc' does not work for some
     reason.  One example is the DECstation, where its RPC library can't
     cope with our redefinition of `malloc' to call `mmalloc'.  When
     defining `USE_MMALLOC', you will also have to set `MMALLOC' in the
     Makefile, to point to the `mmalloc' library.  This define is set
     when you configure with `--with-mmalloc'.

`NO_MMCHECK'
     Define this if you are using `mmalloc', but don't want the overhead
     of checking the heap with `mmcheck'.  Note that on some systems,
     the C runtime makes calls to `malloc' prior to calling `main', and
     if `free' is ever called with these pointers after calling
     `mmcheck' to enable checking, a memory corruption abort is certain
     to occur.  These systems can still use `mmalloc', but must define
     `NO_MMCHECK'.

`MMCHECK_FORCE'
     Define this to 1 if the C runtime allocates memory prior to
     `mmcheck' being called, but that memory is never freed so we don't
     have to worry about it triggering a memory corruption abort.  The
     default is 0, which means that `mmcheck' will only install the heap
     checking functions if there has not yet been any memory allocation
     calls, and if it fails to install the functions, GDB will issue a
     warning.  This is currently defined if you configure using
     `--with-mmalloc'.

`NO_SIGINTERRUPT'
     Define this to indicate that `siginterrupt' is not available.

`SEEK_CUR'
`SEEK_SET'
     Define these to appropriate value for the system `lseek', if not
     already defined.

`STOP_SIGNAL'
     This is the signal for stopping GDB.  Defaults to `SIGTSTP'.
     (Only redefined for the Convex.)

`USE_O_NOCTTY'
     Define this if the interior's tty should be opened with the
     `O_NOCTTY' flag.  (FIXME: This should be a native-only flag, but
     `inflow.c' is always linked in.)

`USG'
     Means that System V (prior to SVR4) include files are in use.
     (FIXME: This symbol is abused in `infrun.c', `regex.c',
     `remote-nindy.c', and `utils.c' for other things, at the moment.)

`lint'
     Define this to help placate `lint' in some situations.

`volatile'
     Define this to override the defaults of `__volatile__' or `/**/'.