Subversion Repositories or1k

\input texinfo

\input texinfo

@setfilename gdbint.info

@setfilename gdbint.info

@ifinfo

@ifinfo

@format

@format

START-INFO-DIR-ENTRY

START-INFO-DIR-ENTRY

* Gdb-Internals: (gdbint).      The GNU debugger's internals.

* Gdb-Internals: (gdbint).      The GNU debugger's internals.

END-INFO-DIR-ENTRY

END-INFO-DIR-ENTRY

@end format

@end format

@end ifinfo

@end ifinfo

@ifinfo

@ifinfo

This file documents the internals of the GNU debugger GDB.

This file documents the internals of the GNU debugger GDB.

Copyright 1990-1999 Free Software Foundation, Inc.

Copyright 1990-1999 Free Software Foundation, Inc.

Contributed by Cygnus Solutions.  Written by John Gilmore.

Contributed by Cygnus Solutions.  Written by John Gilmore.

Second Edition by Stan Shebs.

Second Edition by Stan Shebs.

Permission is granted to make and distribute verbatim copies of this

Permission is granted to make and distribute verbatim copies of this

manual provided the copyright notice and this permission notice are

manual provided the copyright notice and this permission notice are

preserved on all copies.

preserved on all copies.

@ignore

@ignore

Permission is granted to process this file through Tex and print the

Permission is granted to process this file through Tex and print the

results, provided the printed document carries copying permission notice

results, provided the printed document carries copying permission notice

identical to this one except for the removal of this paragraph (this

identical to this one except for the removal of this paragraph (this

paragraph not being relevant to the printed manual).

paragraph not being relevant to the printed manual).

@end ignore

@end ignore

Permission is granted to copy or distribute modified versions of this

Permission is granted to copy or distribute modified versions of this

manual under the terms of the GPL (for which purpose this text may be

manual under the terms of the GPL (for which purpose this text may be

regarded as a program in the language TeX).

regarded as a program in the language TeX).

@end ifinfo

@end ifinfo

@setchapternewpage off

@setchapternewpage off

@settitle GDB Internals

@settitle GDB Internals

@titlepage

@titlepage

@title{GDB Internals}

@title{GDB Internals}

@subtitle{A guide to the internals of the GNU debugger}

@subtitle{A guide to the internals of the GNU debugger}

@author John Gilmore

@author John Gilmore

@author Cygnus Solutions

@author Cygnus Solutions

@author Second Edition:

@author Second Edition:

@author Stan Shebs

@author Stan Shebs

@author Cygnus Solutions

@author Cygnus Solutions

@page

@page

@tex

@tex

\def\$#1${{#1}}  % Kluge: collect RCS revision info without $...$

\def\$#1${{#1}}  % Kluge: collect RCS revision info without $...$

\xdef\manvers{\$Revision: 1.1.1.1 $}  % For use in headers, footers too

\xdef\manvers{\$Revision: 1.1.1.1 $}  % For use in headers, footers too

{\parskip=0pt

{\parskip=0pt

\hfill Cygnus Solutions\par

\hfill Cygnus Solutions\par

\hfill \manvers\par

\hfill \manvers\par

\hfill \TeX{}info \texinfoversion\par

\hfill \TeX{}info \texinfoversion\par

}

}

@end tex

@end tex

@vskip 0pt plus 1filll

@vskip 0pt plus 1filll

Copyright @copyright{} 1990-1999 Free Software Foundation, Inc.

Copyright @copyright{} 1990-1999 Free Software Foundation, Inc.

Permission is granted to make and distribute verbatim copies of

Permission is granted to make and distribute verbatim copies of

this manual provided the copyright notice and this permission notice

this manual provided the copyright notice and this permission notice

are preserved on all copies.

are preserved on all copies.

@end titlepage

@end titlepage

@node Top

@node Top

@c Perhaps this should be the title of the document (but only for info,

@c Perhaps this should be the title of the document (but only for info,

@c not for TeX).  Existing GNU manuals seem inconsistent on this point.

@c not for TeX).  Existing GNU manuals seem inconsistent on this point.

@top Scope of this Document

@top Scope of this Document

This document documents the internals of the GNU debugger, GDB.  It

This document documents the internals of the GNU debugger, GDB.  It

includes description of GDB's key algorithms and operations, as well

includes description of GDB's key algorithms and operations, as well

as the mechanisms that adapt GDB to specific hosts and targets.

as the mechanisms that adapt GDB to specific hosts and targets.

@menu

@menu

* Requirements::

* Requirements::

* Overall Structure::

* Overall Structure::

* Algorithms::

* Algorithms::

* User Interface::

* User Interface::

* Symbol Handling::

* Symbol Handling::

* Language Support::

* Language Support::

* Host Definition::

* Host Definition::

* Target Architecture Definition::

* Target Architecture Definition::

* Target Vector Definition::

* Target Vector Definition::

* Native Debugging::

* Native Debugging::

* Support Libraries::

* Support Libraries::

* Coding::

* Coding::

* Porting GDB::

* Porting GDB::

* Testsuite::

* Testsuite::

* Hints::

* Hints::

@end menu

@end menu

@node Requirements

@node Requirements

@chapter Requirements

@chapter Requirements

Before diving into the internals, you should understand the formal

Before diving into the internals, you should understand the formal

requirements and other expectations for GDB.  Although some of these may

requirements and other expectations for GDB.  Although some of these may

seem obvious, there have been proposals for GDB that have run counter to

seem obvious, there have been proposals for GDB that have run counter to

these requirements.

these requirements.

First of all, GDB is a debugger.  It's not designed to be a front panel

First of all, GDB is a debugger.  It's not designed to be a front panel

for embedded systems.  It's not a text editor.  It's not a shell.  It's

for embedded systems.  It's not a text editor.  It's not a shell.  It's

not a programming environment.

not a programming environment.

GDB is an interactive tool.  Although a batch mode is available, GDB's

GDB is an interactive tool.  Although a batch mode is available, GDB's

primary role is to interact with a human programmer.

primary role is to interact with a human programmer.

GDB should be responsive to the user.  A programmer hot on the trail of

GDB should be responsive to the user.  A programmer hot on the trail of

a nasty bug, and operating under a looming deadline, is going to be very

a nasty bug, and operating under a looming deadline, is going to be very

impatient of everything, including the response time to debugger

impatient of everything, including the response time to debugger

commands.

commands.

GDB should be relatively permissive, such as for expressions.  While the

GDB should be relatively permissive, such as for expressions.  While the

compiler should be picky (or have the option to be made picky), since

compiler should be picky (or have the option to be made picky), since

source code lives for a long time usually, the programmer doing

source code lives for a long time usually, the programmer doing

debugging shouldn't be spending time figuring out to mollify the

debugging shouldn't be spending time figuring out to mollify the

debugger.

debugger.

GDB will be called upon to deal with really large programs.  Executable

GDB will be called upon to deal with really large programs.  Executable

sizes of 50 to 100 megabytes occur regularly, and we've heard reports of

sizes of 50 to 100 megabytes occur regularly, and we've heard reports of

programs approaching 1 gigabyte in size.

programs approaching 1 gigabyte in size.

GDB should be able to run everywhere.  No other debugger is available

GDB should be able to run everywhere.  No other debugger is available

for even half as many configurations as GDB supports.

for even half as many configurations as GDB supports.

@node Overall Structure

@node Overall Structure

@chapter Overall Structure

@chapter Overall Structure

GDB consists of three major subsystems: user interface, symbol handling

GDB consists of three major subsystems: user interface, symbol handling

(the ``symbol side''), and target system handling (the ``target side'').

(the ``symbol side''), and target system handling (the ``target side'').

Ther user interface consists of several actual interfaces, plus

Ther user interface consists of several actual interfaces, plus

supporting code.

supporting code.

The symbol side consists of object file readers, debugging info

The symbol side consists of object file readers, debugging info

interpreters, symbol table management, source language expression

interpreters, symbol table management, source language expression

parsing, type and value printing.

parsing, type and value printing.

The target side consists of execution control, stack frame analysis, and

The target side consists of execution control, stack frame analysis, and

physical target manipulation.

physical target manipulation.

The target side/symbol side division is not formal, and there are a

The target side/symbol side division is not formal, and there are a

number of exceptions.  For instance, core file support involves symbolic

number of exceptions.  For instance, core file support involves symbolic

elements (the basic core file reader is in BFD) and target elements (it

elements (the basic core file reader is in BFD) and target elements (it

supplies the contents of memory and the values of registers).  Instead,

supplies the contents of memory and the values of registers).  Instead,

this division is useful for understanding how the minor subsystems

this division is useful for understanding how the minor subsystems

should fit together.

should fit together.

@section The Symbol Side

@section The Symbol Side

The symbolic side of GDB can be thought of as ``everything you can do in

The symbolic side of GDB can be thought of as ``everything you can do in

GDB without having a live program running''.  For instance, you can look

GDB without having a live program running''.  For instance, you can look

at the types of variables, and evaluate many kinds of expressions.

at the types of variables, and evaluate many kinds of expressions.

@section The Target Side

@section The Target Side

The target side of GDB is the ``bits and bytes manipulator''.  Although

The target side of GDB is the ``bits and bytes manipulator''.  Although

it may make reference to symbolic info here and there, most of the

it may make reference to symbolic info here and there, most of the

target side will run with only a stripped executable available -- or

target side will run with only a stripped executable available -- or

even no executable at all, in remote debugging cases.

even no executable at all, in remote debugging cases.

Operations such as disassembly, stack frame crawls, and register

Operations such as disassembly, stack frame crawls, and register

display, are able to work with no symbolic info at all.  In some cases,

display, are able to work with no symbolic info at all.  In some cases,

such as disassembly, GDB will use symbolic info to present addresses

such as disassembly, GDB will use symbolic info to present addresses

relative to symbols rather than as raw numbers, but it will work either

relative to symbols rather than as raw numbers, but it will work either

way.

way.

@section Configurations

@section Configurations

@dfn{Host} refers to attributes of the system where GDB runs.

@dfn{Host} refers to attributes of the system where GDB runs.

@dfn{Target} refers to the system where the program being debugged

@dfn{Target} refers to the system where the program being debugged

executes.  In most cases they are the same machine, in which case a

executes.  In most cases they are the same machine, in which case a

third type of @dfn{Native} attributes come into play.

third type of @dfn{Native} attributes come into play.

Defines and include files needed to build on the host are host support.

Defines and include files needed to build on the host are host support.

Examples are tty support, system defined types, host byte order, host

Examples are tty support, system defined types, host byte order, host

float format.

float format.

Defines and information needed to handle the target format are target

Defines and information needed to handle the target format are target

dependent.  Examples are the stack frame format, instruction set,

dependent.  Examples are the stack frame format, instruction set,

breakpoint instruction, registers, and how to set up and tear down the stack

breakpoint instruction, registers, and how to set up and tear down the stack

to call a function.

to call a function.

Information that is only needed when the host and target are the same,

Information that is only needed when the host and target are the same,

is native dependent.  One example is Unix child process support; if the

is native dependent.  One example is Unix child process support; if the

host and target are not the same, doing a fork to start the target

host and target are not the same, doing a fork to start the target

process is a bad idea.  The various macros needed for finding the

process is a bad idea.  The various macros needed for finding the

registers in the @code{upage}, running @code{ptrace}, and such are all

registers in the @code{upage}, running @code{ptrace}, and such are all

in the native-dependent files.

in the native-dependent files.

Another example of native-dependent code is support for features that

Another example of native-dependent code is support for features that

are really part of the target environment, but which require

are really part of the target environment, but which require

@code{#include} files that are only available on the host system.  Core

@code{#include} files that are only available on the host system.  Core

file handling and @code{setjmp} handling are two common cases.

file handling and @code{setjmp} handling are two common cases.

When you want to make GDB work ``native'' on a particular machine, you

When you want to make GDB work ``native'' on a particular machine, you

have to include all three kinds of information.

have to include all three kinds of information.

@node Algorithms

@node Algorithms

@chapter Algorithms

@chapter Algorithms

GDB uses a number of debugging-specific algorithms.  They are often not

GDB uses a number of debugging-specific algorithms.  They are often not

very complicated, but get lost in the thicket of special cases and

very complicated, but get lost in the thicket of special cases and

real-world issues.  This chapter describes the basic algorithms and

real-world issues.  This chapter describes the basic algorithms and

mentions some of the specific target definitions that they use.

mentions some of the specific target definitions that they use.

@section Frames

@section Frames

A frame is a construct that GDB uses to keep track of calling and called

A frame is a construct that GDB uses to keep track of calling and called

functions.

functions.

@code{FRAME_FP} in the machine description has no meaning to the

@code{FRAME_FP} in the machine description has no meaning to the

machine-independent part of GDB, except that it is used when setting up

machine-independent part of GDB, except that it is used when setting up

a new frame from scratch, as follows:

a new frame from scratch, as follows:

@example

@example

      create_new_frame (read_register (FP_REGNUM), read_pc ()));

      create_new_frame (read_register (FP_REGNUM), read_pc ()));

@end example

@end example

Other than that, all the meaning imparted to @code{FP_REGNUM} is

Other than that, all the meaning imparted to @code{FP_REGNUM} is

imparted by the machine-dependent code.  So, @code{FP_REGNUM} can have

imparted by the machine-dependent code.  So, @code{FP_REGNUM} can have

any value that is convenient for the code that creates new frames.

any value that is convenient for the code that creates new frames.

(@code{create_new_frame} calls @code{INIT_EXTRA_FRAME_INFO} if it is

(@code{create_new_frame} calls @code{INIT_EXTRA_FRAME_INFO} if it is

defined; that is where you should use the @code{FP_REGNUM} value, if

defined; that is where you should use the @code{FP_REGNUM} value, if

your frames are nonstandard.)

your frames are nonstandard.)

Given a GDB frame, define @code{FRAME_CHAIN} to determine the address of

Given a GDB frame, define @code{FRAME_CHAIN} to determine the address of

the calling function's frame.  This will be used to create a new GDB

the calling function's frame.  This will be used to create a new GDB

frame struct, and then @code{INIT_EXTRA_FRAME_INFO} and

frame struct, and then @code{INIT_EXTRA_FRAME_INFO} and

@code{INIT_FRAME_PC} will be called for the new frame.

@code{INIT_FRAME_PC} will be called for the new frame.

@section Breakpoint Handling

@section Breakpoint Handling

In general, a breakpoint is a user-designated location in the program

In general, a breakpoint is a user-designated location in the program

where the user wants to regain control if program execution ever reaches

where the user wants to regain control if program execution ever reaches

that location.

that location.

There are two main ways to implement breakpoints; either as ``hardware''

There are two main ways to implement breakpoints; either as ``hardware''

breakpoints or as ``software'' breakpoints.

breakpoints or as ``software'' breakpoints.

Hardware breakpoints are sometimes available as a builtin debugging

Hardware breakpoints are sometimes available as a builtin debugging

features with some chips.  Typically these work by having dedicated

features with some chips.  Typically these work by having dedicated

register into which the breakpoint address may be stored.  If the PC

register into which the breakpoint address may be stored.  If the PC

ever matches a value in a breakpoint registers, the CPU raises an

ever matches a value in a breakpoint registers, the CPU raises an

exception and reports it to GDB.  Another possibility is when an

exception and reports it to GDB.  Another possibility is when an

emulator is in use; many emulators include circuitry that watches the

emulator is in use; many emulators include circuitry that watches the

address lines coming out from the processor, and force it to stop if the

address lines coming out from the processor, and force it to stop if the

address matches a breakpoint's address.  A third possibility is that the

address matches a breakpoint's address.  A third possibility is that the

target already has the ability to do breakpoints somehow; for instance,

target already has the ability to do breakpoints somehow; for instance,

a ROM monitor may do its own software breakpoints.  So although these

a ROM monitor may do its own software breakpoints.  So although these

are not literally ``hardware breakpoints'', from GDB's point of view

are not literally ``hardware breakpoints'', from GDB's point of view

they work the same; GDB need not do nothing more than set the breakpoint

they work the same; GDB need not do nothing more than set the breakpoint

and wait for something to happen.

and wait for something to happen.

Since they depend on hardware resources, hardware breakpoints may be

Since they depend on hardware resources, hardware breakpoints may be

limited in number; when the user asks for more, GDB will start trying to

limited in number; when the user asks for more, GDB will start trying to

set software breakpoints.

set software breakpoints.

Software breakpoints require GDB to do somewhat more work.  The basic

Software breakpoints require GDB to do somewhat more work.  The basic

theory is that GDB will replace a program instruction with a trap,

theory is that GDB will replace a program instruction with a trap,

illegal divide, or some other instruction that will cause an exception,

illegal divide, or some other instruction that will cause an exception,

and then when it's encountered, GDB will take the exception and stop the

and then when it's encountered, GDB will take the exception and stop the

program. When the user says to continue, GDB will restore the original

program. When the user says to continue, GDB will restore the original

instruction, single-step, re-insert the trap, and continue on.

instruction, single-step, re-insert the trap, and continue on.

Since it literally overwrites the program being tested, the program area

Since it literally overwrites the program being tested, the program area

must be writeable, so this technique won't work on programs in ROM.  It

must be writeable, so this technique won't work on programs in ROM.  It

can also distort the behavior of programs that examine themselves,

can also distort the behavior of programs that examine themselves,

although the situation would be highly unusual.

although the situation would be highly unusual.

Also, the software breakpoint instruction should be the smallest size of

Also, the software breakpoint instruction should be the smallest size of

instruction, so it doesn't overwrite an instruction that might be a jump

instruction, so it doesn't overwrite an instruction that might be a jump

target, and cause disaster when the program jumps into the middle of the

target, and cause disaster when the program jumps into the middle of the

breakpoint instruction.  (Strictly speaking, the breakpoint must be no

breakpoint instruction.  (Strictly speaking, the breakpoint must be no

larger than the smallest interval between instructions that may be jump

larger than the smallest interval between instructions that may be jump

targets; perhaps there is an architecture where only even-numbered

targets; perhaps there is an architecture where only even-numbered

instructions may jumped to.)  Note that it's possible for an instruction

instructions may jumped to.)  Note that it's possible for an instruction

set not to have any instructions usable for a software breakpoint,

set not to have any instructions usable for a software breakpoint,

although in practice only the ARC has failed to define such an

although in practice only the ARC has failed to define such an

instruction.

instruction.

The basic definition of the software breakpoint is the macro

The basic definition of the software breakpoint is the macro

@code{BREAKPOINT}.

@code{BREAKPOINT}.

Basic breakpoint object handling is in @file{breakpoint.c}.  However,

Basic breakpoint object handling is in @file{breakpoint.c}.  However,

much of the interesting breakpoint action is in @file{infrun.c}.

much of the interesting breakpoint action is in @file{infrun.c}.

@section Single Stepping

@section Single Stepping

@section Signal Handling

@section Signal Handling

@section Thread Handling

@section Thread Handling

@section Inferior Function Calls

@section Inferior Function Calls

@section Longjmp Support

@section Longjmp Support

GDB has support for figuring out that the target is doing a

GDB has support for figuring out that the target is doing a

@code{longjmp} and for stopping at the target of the jump, if we are

@code{longjmp} and for stopping at the target of the jump, if we are

stepping.  This is done with a few specialized internal breakpoints,

stepping.  This is done with a few specialized internal breakpoints,

which are visible in the @code{maint info breakpoint} command.

which are visible in the @code{maint info breakpoint} command.

To make this work, you need to define a macro called

To make this work, you need to define a macro called

@code{GET_LONGJMP_TARGET}, which will examine the @code{jmp_buf}

@code{GET_LONGJMP_TARGET}, which will examine the @code{jmp_buf}

structure and extract the longjmp target address.  Since @code{jmp_buf}

structure and extract the longjmp target address.  Since @code{jmp_buf}

is target specific, you will need to define it in the appropriate

is target specific, you will need to define it in the appropriate

@file{tm-@var{xyz}.h} file.  Look in @file{tm-sun4os4.h} and

@file{tm-@var{xyz}.h} file.  Look in @file{tm-sun4os4.h} and

@file{sparc-tdep.c} for examples of how to do this.

@file{sparc-tdep.c} for examples of how to do this.

@node User Interface

@node User Interface

@chapter User Interface

@chapter User Interface

GDB has several user interfaces.  Although the command-line interface

GDB has several user interfaces.  Although the command-line interface

is the most common and most familiar, there are others.

is the most common and most familiar, there are others.

@section Command Interpreter

@section Command Interpreter

The command interpreter in GDB is fairly simple.  It is designed to

The command interpreter in GDB is fairly simple.  It is designed to

allow for the set of commands to be augmented dynamically, and also

allow for the set of commands to be augmented dynamically, and also

has a recursive subcommand capability, where the first argument to

has a recursive subcommand capability, where the first argument to

a command may itself direct a lookup on a different command list.

a command may itself direct a lookup on a different command list.

For instance, the @code{set} command just starts a lookup on the

For instance, the @code{set} command just starts a lookup on the

@code{setlist} command list, while @code{set thread} recurses

@code{setlist} command list, while @code{set thread} recurses

to the @code{set_thread_cmd_list}.

to the @code{set_thread_cmd_list}.

To add commands in general, use @code{add_cmd}.  @code{add_com} adds to

To add commands in general, use @code{add_cmd}.  @code{add_com} adds to

the main command list, and should be used for those commands.  The usual

the main command list, and should be used for those commands.  The usual

place to add commands is in the @code{_initialize_@var{xyz}} routines at

place to add commands is in the @code{_initialize_@var{xyz}} routines at

the ends of most source files.

the ends of most source files.

Before removing commands from the command set it is a good idea to

Before removing commands from the command set it is a good idea to

deprecate them for some time.  Use @code{deprecate_cmd} on commands or

deprecate them for some time.  Use @code{deprecate_cmd} on commands or

aliases to set the deprecated flag.  @code{deprecate_cmd} takes a

aliases to set the deprecated flag.  @code{deprecate_cmd} takes a

@code{struct cmd_list_element} as it's first argument.  You can use the

@code{struct cmd_list_element} as it's first argument.  You can use the

return value from @code{add_com} or @code{add_cmd} to deprecate the

return value from @code{add_com} or @code{add_cmd} to deprecate the

command immediately after it is created.

command immediately after it is created.

The first time a comamnd is used the user will be warned and offered a

The first time a comamnd is used the user will be warned and offered a

replacement (if one exists). Note that the replacement string passed to

replacement (if one exists). Note that the replacement string passed to

@code{deprecate_cmd} should be the full name of the command, i.e. the

@code{deprecate_cmd} should be the full name of the command, i.e. the

entire string the user should type at the command line.

entire string the user should type at the command line.

@section Console Printing

@section Console Printing

@section TUI

@section TUI

@section libgdb

@section libgdb

@code{libgdb} was an abortive project of years ago.  The theory was to

@code{libgdb} was an abortive project of years ago.  The theory was to

provide an API to GDB's functionality.

provide an API to GDB's functionality.

@node Symbol Handling

@node Symbol Handling

@chapter Symbol Handling

@chapter Symbol Handling

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

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

functions, and types.

functions, and types.

@section Symbol Reading

@section Symbol Reading

GDB reads symbols from ``symbol files''.  The usual symbol file is the

GDB reads symbols from ``symbol files''.  The usual symbol file is the

file containing the program which GDB is debugging.  GDB can be directed

file containing the program which GDB is debugging.  GDB can be directed

to use a different file for symbols (with the @code{symbol-file}

to use a different file for symbols (with the @code{symbol-file}

command), and it can also read more symbols via the ``add-file'' and

command), and it can also read more symbols via the ``add-file'' and

``load'' commands, or while reading symbols from shared libraries.

``load'' commands, or while reading symbols from shared libraries.

Symbol files are initially opened by code in @file{symfile.c} using the

Symbol files are initially opened by code in @file{symfile.c} using the

BFD library.  BFD identifies the type of the file by examining its

BFD library.  BFD identifies the type of the file by examining its

header.  @code{find_sym_fns} then uses this identification to locate a

header.  @code{find_sym_fns} then uses this identification to locate a

set of symbol-reading functions.

set of symbol-reading functions.

Symbol reading modules identify themselves to GDB by calling

Symbol reading modules identify themselves to GDB by calling

@code{add_symtab_fns} during their module initialization.  The argument

@code{add_symtab_fns} during their module initialization.  The argument

to @code{add_symtab_fns} is a @code{struct sym_fns} which contains the

to @code{add_symtab_fns} is a @code{struct sym_fns} which contains the

name (or name prefix) of the symbol format, the length of the prefix,

name (or name prefix) of the symbol format, the length of the prefix,

and pointers to four functions.  These functions are called at various

and pointers to four functions.  These functions are called at various

times to process symbol-files whose identification matches the specified

times to process symbol-files whose identification matches the specified

prefix.

prefix.

The functions supplied by each module are:

The functions supplied by each module are:

@table @code

@table @code

@item @var{xyz}_symfile_init(struct sym_fns *sf)

@item @var{xyz}_symfile_init(struct sym_fns *sf)

Called from @code{symbol_file_add} when we are about to read a new

Called from @code{symbol_file_add} when we are about to read a new

symbol file.  This function should clean up any internal state (possibly

symbol file.  This function should clean up any internal state (possibly

resulting from half-read previous files, for example) and prepare to

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

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

might be a new "main" symbol file, or might be a secondary symbol file

whose symbols are being added to the existing symbol table.

whose symbols are being added to the existing symbol table.

The argument to @code{@var{xyz}_symfile_init} is a newly allocated

The argument to @code{@var{xyz}_symfile_init} is a newly allocated

@code{struct sym_fns} whose @code{bfd} field contains the BFD for the

@code{struct sym_fns} whose @code{bfd} field contains the BFD for the

new symbol file being read.  Its @code{private} field has been zeroed,

new symbol file being read.  Its @code{private} field has been zeroed,

and can be modified as desired.  Typically, a struct of private

and can be modified as desired.  Typically, a struct of private

information will be @code{malloc}'d, and a pointer to it will be placed

information will be @code{malloc}'d, and a pointer to it will be placed

in the @code{private} field.

in the @code{private} field.

There is no result from @code{@var{xyz}_symfile_init}, but it can call

There is no result from @code{@var{xyz}_symfile_init}, but it can call

@code{error} if it detects an unavoidable problem.

@code{error} if it detects an unavoidable problem.

@item @var{xyz}_new_init()

@item @var{xyz}_new_init()

Called from @code{symbol_file_add} when discarding existing symbols.

Called from @code{symbol_file_add} when discarding existing symbols.

This function need only handle the symbol-reading module's internal

This function need only handle the symbol-reading module's internal

state; the symbol table data structures visible to the rest of GDB will

state; the symbol table data structures visible to the rest of GDB will

be discarded by @code{symbol_file_add}.  It has no arguments and no

be discarded by @code{symbol_file_add}.  It has no arguments and no

result.  It may be called after @code{@var{xyz}_symfile_init}, if a new

result.  It may be called after @code{@var{xyz}_symfile_init}, if a new

symbol table is being read, or may be called alone if all symbols are

symbol table is being read, or may be called alone if all symbols are

simply being discarded.

simply being discarded.

@item @var{xyz}_symfile_read(struct sym_fns *sf, CORE_ADDR addr, int mainline)

@item @var{xyz}_symfile_read(struct sym_fns *sf, CORE_ADDR addr, int mainline)

Called from @code{symbol_file_add} to actually read the symbols from a

Called from @code{symbol_file_add} to actually read the symbols from a

symbol-file into a set of psymtabs or symtabs.

symbol-file into a set of psymtabs or symtabs.

@code{sf} points to the struct sym_fns originally passed to

@code{sf} points to the struct sym_fns originally passed to

@code{@var{xyz}_sym_init} for possible initialization.  @code{addr} is

@code{@var{xyz}_sym_init} for possible initialization.  @code{addr} is

the offset between the file's specified start address and its true

the offset between the file's specified start address and its true

address in memory.  @code{mainline} is 1 if this is the main symbol

address in memory.  @code{mainline} is 1 if this is the main symbol

table being read, and 0 if a secondary symbol file (e.g. shared library

table being read, and 0 if a secondary symbol file (e.g. shared library

or dynamically loaded file) is being read.@refill

or dynamically loaded file) is being read.@refill

@end table

@end table

In addition, if a symbol-reading module creates psymtabs when

In addition, if a symbol-reading module creates psymtabs when

@var{xyz}_symfile_read is called, these psymtabs will contain a pointer

@var{xyz}_symfile_read is called, these psymtabs will contain a pointer

to a function @code{@var{xyz}_psymtab_to_symtab}, which can be called

to a function @code{@var{xyz}_psymtab_to_symtab}, which can be called

from any point in the GDB symbol-handling code.

from any point in the GDB symbol-handling code.

@table @code

@table @code

@item @var{xyz}_psymtab_to_symtab (struct partial_symtab *pst)

@item @var{xyz}_psymtab_to_symtab (struct partial_symtab *pst)

Called from @code{psymtab_to_symtab} (or the PSYMTAB_TO_SYMTAB macro) if

Called from @code{psymtab_to_symtab} (or the PSYMTAB_TO_SYMTAB macro) if

the psymtab has not already been read in and had its @code{pst->symtab}

the psymtab has not already been read in and had its @code{pst->symtab}

pointer set.  The argument is the psymtab to be fleshed-out into a

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

symtab.  Upon return, pst->readin should have been set to 1, and

pst->symtab should contain a pointer to the new corresponding symtab, or

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.

zero if there were no symbols in that part of the symbol file.

@end table

@end table

@section Partial Symbol Tables

@section Partial Symbol Tables

GDB has three types of symbol tables.

GDB has three types of symbol tables.

@itemize @bullet

@itemize @bullet

@item full symbol tables (symtabs).  These contain the main information

@item full symbol tables (symtabs).  These contain the main information

about symbols and addresses.

about symbols and addresses.

@item partial symbol tables (psymtabs).  These contain enough

@item partial symbol tables (psymtabs).  These contain enough

information to know when to read the corresponding part of the full

information to know when to read the corresponding part of the full

symbol table.

symbol table.

@item minimal symbol tables (msymtabs).  These contain information

@item minimal symbol tables (msymtabs).  These contain information

gleaned from non-debugging symbols.

gleaned from non-debugging symbols.

@end itemize

@end itemize

This section describes partial symbol tables.

This section describes partial symbol tables.

A psymtab is constructed by doing a very quick pass over an executable

A psymtab is constructed by doing a very quick pass over an executable

file's debugging information.  Small amounts of information are

file's debugging information.  Small amounts of information are

extracted -- enough to identify which parts of the symbol table will

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

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

information.  The speed of this pass causes GDB to start up very

quickly.  Later, as the detailed rereading occurs, it occurs in small

quickly.  Later, as the detailed rereading occurs, it occurs in small

pieces, at various times, and the delay therefrom is mostly invisible to

pieces, at various times, and the delay therefrom is mostly invisible to

the user.

the user.

@c (@xref{Symbol Reading}.)

@c (@xref{Symbol Reading}.)

The symbols that show up in a file's psymtab should be, roughly, those

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

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

that file.  These include external symbols and types, static symbols and

types, and enum values declared at file scope.

types, and enum values declared at file scope.

The psymtab also contains the range of instruction addresses that the

The psymtab also contains the range of instruction addresses that the

full symbol table would represent.

full symbol table would represent.

The idea is that there are only two ways for the user (or much of the

The idea is that there are only two ways for the user (or much of the

code in the debugger) to reference a symbol:

code in the debugger) to reference a symbol:

@itemize @bullet

@itemize @bullet

@item by its address

@item by its address

(e.g. execution stops at some address which is inside a function in this

(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,

file).  The address will be noticed to be in the range of this psymtab,

and the full symtab will be read in.  @code{find_pc_function},

and the full symtab will be read in.  @code{find_pc_function},

@code{find_pc_line}, and other @code{find_pc_@dots{}} functions handle

@code{find_pc_line}, and other @code{find_pc_@dots{}} functions handle

this.

this.

@item by its name

@item by its name

(e.g. the user asks to print a variable, or set a breakpoint on a

(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

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

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

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

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

qualifier.  Or, a local symbol can be referenced when we are "in" a

local scope, in which case the first case applies.  @code{lookup_symbol}

local scope, in which case the first case applies.  @code{lookup_symbol}

does most of the work here.

does most of the work here.

@end itemize

@end itemize

The only reason that psymtabs exist is to cause a symtab to be read in

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,

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

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

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,

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

either, so types need not appear, unless they will be referenced by

name.

name.

It is a bug for GDB to behave one way when only a psymtab has been read,

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

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

are typically caused by a psymtab that does not contain all the visible

symbols, or which has the wrong instruction address ranges.

symbols, or which has the wrong instruction address ranges.

The psymtab for a particular section of a symbol-file (objfile) could be

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

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

be searched before the psymtab, so the psymtab will never be used (in a

bug-free environment).  Currently, psymtabs are allocated on an obstack,

bug-free environment).  Currently, psymtabs are allocated on an obstack,

and all the psymbols themselves are allocated in a pair of large arrays

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

on an obstack, so there is little to be gained by trying to free them

unless you want to do a lot more work.

unless you want to do a lot more work.

@section Types

@section Types

Fundamental Types (e.g., FT_VOID, FT_BOOLEAN).

Fundamental Types (e.g., FT_VOID, FT_BOOLEAN).

These are the fundamental types that GDB uses internally.  Fundamental

These are the fundamental types that GDB uses internally.  Fundamental

types from the various debugging formats (stabs, ELF, etc) are mapped

types from the various debugging formats (stabs, ELF, etc) are mapped

into one of these.  They are basically a union of all fundamental types

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.

that gdb knows about for all the languages that GDB knows about.

Type Codes (e.g., TYPE_CODE_PTR, TYPE_CODE_ARRAY).

Type Codes (e.g., TYPE_CODE_PTR, TYPE_CODE_ARRAY).

Each time GDB builds an internal type, it marks it with one of these

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

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.

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

Typically, several FT_* types map to one TYPE_CODE_* type, and are

distinguished by other members of the type struct, such as whether the

distinguished by other members of the type struct, such as whether the

type is signed or unsigned, and how many bits it uses.

type is signed or unsigned, and how many bits it uses.

Builtin Types (e.g., builtin_type_void, builtin_type_char).

Builtin Types (e.g., builtin_type_void, builtin_type_char).

These are instances of type structs that roughly correspond to

These are instances of type structs that roughly correspond to

fundamental types and are created as global types for GDB to use for

fundamental types and are created as global types for GDB to use for

various ugly historical reasons.  We eventually want to eliminate these.

various ugly historical reasons.  We eventually want to eliminate these.

Note for example that builtin_type_int initialized in gdbtypes.c is

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

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

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

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

instance exists, while c-lang.c builds as many TYPE_CODE_INT types as

needed, with each one associated with some particular objfile.

needed, with each one associated with some particular objfile.

@section Object File Formats

@section Object File Formats

@subsection a.out

@subsection a.out

The @file{a.out} format is the original file format for Unix.  It

The @file{a.out} format is the original file format for Unix.  It

consists of three sections: text, data, and bss, which are for program

consists of three sections: text, data, and bss, which are for program

code, initialized data, and uninitialized data, respectively.

code, initialized data, and uninitialized data, respectively.

The @file{a.out} format is so simple that it doesn't have any reserved

The @file{a.out} format is so simple that it doesn't have any reserved

place for debugging information.  (Hey, the original Unix hackers used

place for debugging information.  (Hey, the original Unix hackers used

@file{adb}, which is a machine-language debugger.)  The only debugging

@file{adb}, which is a machine-language debugger.)  The only debugging

format for @file{a.out} is stabs, which is encoded as a set of normal

format for @file{a.out} is stabs, which is encoded as a set of normal

symbols with distinctive attributes.

symbols with distinctive attributes.

The basic @file{a.out} reader is in @file{dbxread.c}.

The basic @file{a.out} reader is in @file{dbxread.c}.

@subsection COFF

@subsection COFF

The COFF format was introduced with System V Release 3 (SVR3) Unix.

The COFF format was introduced with System V Release 3 (SVR3) Unix.

COFF files may have multiple sections, each prefixed by a header.  The

COFF files may have multiple sections, each prefixed by a header.  The

number of sections is limited.

number of sections is limited.

The COFF specification includes support for debugging.  Although this

The COFF specification includes support for debugging.  Although this

was a step forward, the debugging information was woefully limited.  For

was a step forward, the debugging information was woefully limited.  For

instance, it was not possible to represent code that came from an

instance, it was not possible to represent code that came from an

included file.

included file.

The COFF reader is in @file{coffread.c}.

The COFF reader is in @file{coffread.c}.

@subsection ECOFF

@subsection ECOFF

ECOFF is an extended COFF originally introduced for Mips and Alpha

ECOFF is an extended COFF originally introduced for Mips and Alpha

workstations.

workstations.

The basic ECOFF reader is in @file{mipsread.c}.

The basic ECOFF reader is in @file{mipsread.c}.

@subsection XCOFF

@subsection XCOFF

The IBM RS/6000 running AIX uses an object file format called 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

The COFF sections, symbols, and line numbers are used, but debugging

symbols are dbx-style stabs whose strings are located in the

symbols are dbx-style stabs whose strings are located in the

@samp{.debug} section (rather than the string table).  For more

@samp{.debug} section (rather than the string table).  For more

information, see @xref{Top,,,stabs,The Stabs Debugging Format}.

information, see @xref{Top,,,stabs,The Stabs Debugging Format}.

The shared library scheme has a clean interface for figuring out what

The shared library scheme has a clean interface for figuring out what

shared libraries are in use, but the catch is that everything which

shared libraries are in use, but the catch is that everything which

refers to addresses (symbol tables and breakpoints at least) needs to be

refers to addresses (symbol tables and breakpoints at least) needs to be

relocated for both shared libraries and the main executable.  At least

relocated for both shared libraries and the main executable.  At least

using the standard mechanism this can only be done once the program has

using the standard mechanism this can only be done once the program has

been run (or the core file has been read).

been run (or the core file has been read).

@subsection PE

@subsection PE

Windows 95 and NT use the PE (Portable Executable) format for their

Windows 95 and NT use the PE (Portable Executable) format for their

executables.  PE is basically COFF with additional headers.

executables.  PE is basically COFF with additional headers.

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

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

COFF reader.

COFF reader.

@subsection ELF

@subsection ELF

The ELF format came with System V Release 4 (SVR4) Unix.  ELF is similar

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

to COFF in being organized into a number of sections, but it removes

many of COFF's limitations.

many of COFF's limitations.

The basic ELF reader is in @file{elfread.c}.

The basic ELF reader is in @file{elfread.c}.

@subsection SOM

@subsection SOM

SOM is HP's object file and debug format (not to be confused with IBM's

SOM is HP's object file and debug format (not to be confused with IBM's

SOM, which is a cross-language ABI).

SOM, which is a cross-language ABI).

The SOM reader is in @file{hpread.c}.

The SOM reader is in @file{hpread.c}.

@subsection Other File Formats

@subsection Other File Formats

Other file formats that have been supported by GDB include Netware

Other file formats that have been supported by GDB include Netware

Loadable Modules (@file{nlmread.c}.

Loadable Modules (@file{nlmread.c}.

@section Debugging File Formats

@section Debugging File Formats

This section describes characteristics of debugging information that

This section describes characteristics of debugging information that

are independent of the object file format.

are independent of the object file format.

@subsection stabs

@subsection stabs

@code{stabs} started out as special symbols within the @code{a.out}

@code{stabs} started out as special symbols within the @code{a.out}

format.  Since then, it has been encapsulated into other file

format.  Since then, it has been encapsulated into other file

formats, such as COFF and ELF.

formats, such as COFF and ELF.

While @file{dbxread.c} does some of the basic stab processing,

While @file{dbxread.c} does some of the basic stab processing,

including for encapsulated versions, @file{stabsread.c} does

including for encapsulated versions, @file{stabsread.c} does

the real work.

the real work.

@subsection COFF

@subsection COFF

The basic COFF definition includes debugging information.  The level

The basic COFF definition includes debugging information.  The level

of support is minimal and non-extensible, and is not often used.

of support is minimal and non-extensible, and is not often used.

@subsection Mips debug (Third Eye)

@subsection Mips debug (Third Eye)

ECOFF includes a definition of a special debug format.

ECOFF includes a definition of a special debug format.

The file @file{mdebugread.c} implements reading for this format.

The file @file{mdebugread.c} implements reading for this format.

@subsection DWARF 1

@subsection DWARF 1

DWARF 1 is a debugging format that was originally designed to be

DWARF 1 is a debugging format that was originally designed to be

used with ELF in SVR4 systems.

used with ELF in SVR4 systems.

@c CHILL_PRODUCER

@c CHILL_PRODUCER

@c GCC_PRODUCER

@c GCC_PRODUCER

@c GPLUS_PRODUCER

@c GPLUS_PRODUCER

@c LCC_PRODUCER

@c LCC_PRODUCER

@c If defined, these are the producer strings in a DWARF 1 file.  All of

@c If defined, these are the producer strings in a DWARF 1 file.  All of

@c these have reasonable defaults already.

@c these have reasonable defaults already.

The DWARF 1 reader is in @file{dwarfread.c}.

The DWARF 1 reader is in @file{dwarfread.c}.

@subsection DWARF 2

@subsection DWARF 2

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

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

The DWARF 2 reader is in @file{dwarf2read.c}.

The DWARF 2 reader is in @file{dwarf2read.c}.

@subsection SOM

@subsection SOM

Like COFF, the SOM definition includes debugging information.

Like COFF, the SOM definition includes debugging information.

@section Adding a New Symbol Reader to GDB

@section Adding a New Symbol Reader to GDB

If you are using an existing object file format (a.out, COFF, ELF, etc),

If you are using an existing object file format (a.out, COFF, ELF, etc),

there is probably little to be done.

there is probably little to be done.

If you need to add a new object file format, you must first add it to

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.

BFD.  This is beyond the scope of this document.

You must then arrange for the BFD code to provide access to the

You must then arrange for the BFD code to provide access to the

debugging symbols.  Generally GDB will have to call swapping routines

debugging symbols.  Generally GDB will have to call swapping routines

from BFD and a few other BFD internal routines to locate the debugging

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

information.  As much as possible, GDB should not depend on the BFD

internal data structures.

internal data structures.

For some targets (e.g., COFF), there is a special transfer vector used

For some targets (e.g., COFF), there is a special transfer vector used

to call swapping routines, since the external data structures on various

to call swapping routines, since the external data structures on various

platforms have different sizes and layouts.  Specialized routines that

platforms have different sizes and layouts.  Specialized routines that

will only ever be implemented by one object file format may be called

will only ever be implemented by one object file format may be called

directly.  This interface should be described in a file

directly.  This interface should be described in a file

@file{bfd/libxyz.h}, which is included by GDB.

@file{bfd/libxyz.h}, which is included by GDB.

@node Language Support

@node Language Support

@chapter Language Support

@chapter Language Support

GDB's language support is mainly driven by the symbol reader, although

GDB's language support is mainly driven by the symbol reader, although

it is possible for the user to set the source language manually.

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

GDB chooses the source language by looking at the extension of the file

recorded in the debug info; @code{.c} means C, @code{.f} means Fortran,

recorded in the debug info; @code{.c} means C, @code{.f} means Fortran,

etc.  It may also use a special-purpose language identifier if the debug

etc.  It may also use a special-purpose language identifier if the debug

format supports it, such as DWARF.

format supports it, such as DWARF.

@section Adding a Source Language to GDB

@section Adding a Source Language to GDB

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

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

steps:

steps:

@table @emph

@table @emph

@item Create the expression parser.

@item Create the expression parser.

This should reside in a file @file{@var{lang}-exp.y}.  Routines for

This should reside in a file @file{@var{lang}-exp.y}.  Routines for

building parsed expressions into a @samp{union exp_element} list are in

building parsed expressions into a @samp{union exp_element} list are in

@file{parse.c}.

@file{parse.c}.

Since we can't depend upon everyone having Bison, and YACC produces

Since we can't depend upon everyone having Bison, and YACC produces

parsers that define a bunch of global names, the following lines

parsers that define a bunch of global names, the following lines

@emph{must} be included at the top of the YACC parser, to prevent the

@emph{must} be included at the top of the YACC parser, to prevent the

various parsers from defining the same global names:

various parsers from defining the same global names:

@example

@example

#define yyparse         @var{lang}_parse

#define yyparse         @var{lang}_parse

#define yylex   @var{lang}_lex

#define yylex   @var{lang}_lex

#define yyerror         @var{lang}_error

#define yyerror         @var{lang}_error

#define yylval  @var{lang}_lval

#define yylval  @var{lang}_lval

#define yychar  @var{lang}_char

#define yychar  @var{lang}_char

#define yydebug         @var{lang}_debug

#define yydebug         @var{lang}_debug

#define yypact          @var{lang}_pact

#define yypact          @var{lang}_pact

#define yyr1            @var{lang}_r1

#define yyr1            @var{lang}_r1

#define yyr2            @var{lang}_r2

#define yyr2            @var{lang}_r2

#define yydef           @var{lang}_def

#define yydef           @var{lang}_def

#define yychk           @var{lang}_chk

#define yychk           @var{lang}_chk

#define yypgo           @var{lang}_pgo

#define yypgo           @var{lang}_pgo

#define yyact   @var{lang}_act

#define yyact   @var{lang}_act

#define yyexca          @var{lang}_exca

#define yyexca          @var{lang}_exca

#define yyerrflag       @var{lang}_errflag

#define yyerrflag       @var{lang}_errflag

#define yynerrs         @var{lang}_nerrs

#define yynerrs         @var{lang}_nerrs

@end example

@end example

At the bottom of your parser, define a @code{struct language_defn} and

At the bottom of your parser, define a @code{struct language_defn} and

initialize it with the right values for your language.  Define an

initialize it with the right values for your language.  Define an

@code{initialize_@var{lang}} routine and have it call

@code{initialize_@var{lang}} routine and have it call

@samp{add_language(@var{lang}_language_defn)} to tell the rest of GDB

@samp{add_language(@var{lang}_language_defn)} to tell the rest of GDB

that your language exists.  You'll need some other supporting variables

that your language exists.  You'll need some other supporting variables

and functions, which will be used via pointers from your

and functions, which will be used via pointers from your

@code{@var{lang}_language_defn}.  See the declaration of @code{struct

@code{@var{lang}_language_defn}.  See the declaration of @code{struct

language_defn} in @file{language.h}, and the other @file{*-exp.y} files,

language_defn} in @file{language.h}, and the other @file{*-exp.y} files,

for more information.

for more information.

@item Add any evaluation routines, if necessary

@item Add any evaluation routines, if necessary

If you need new opcodes (that represent the operations of the language),

If you need new opcodes (that represent the operations of the language),

add them to the enumerated type in @file{expression.h}.  Add support

add them to the enumerated type in @file{expression.h}.  Add support

code for these operations in @code{eval.c:evaluate_subexp()}.  Add cases

code for these operations in @code{eval.c:evaluate_subexp()}.  Add cases

for new opcodes in two functions from @file{parse.c}:

for new opcodes in two functions from @file{parse.c}:

@code{prefixify_subexp()} and @code{length_of_subexp()}.  These compute

@code{prefixify_subexp()} and @code{length_of_subexp()}.  These compute

the number of @code{exp_element}s that a given operation takes up.

the number of @code{exp_element}s that a given operation takes up.

@item Update some existing code

@item Update some existing code

Add an enumerated identifier for your language to the enumerated type

Add an enumerated identifier for your language to the enumerated type

@code{enum language} in @file{defs.h}.

@code{enum language} in @file{defs.h}.

Update the routines in @file{language.c} so your language is included.

Update the routines in @file{language.c} so your language is included.

These routines include type predicates and such, which (in some cases)

These routines include type predicates and such, which (in some cases)

are language dependent.  If your language does not appear in the switch

are language dependent.  If your language does not appear in the switch

statement, an error is reported.

statement, an error is reported.

Also included in @file{language.c} is the code that updates the variable

Also included in @file{language.c} is the code that updates the variable

@code{current_language}, and the routines that translate the

@code{current_language}, and the routines that translate the

@code{language_@var{lang}} enumerated identifier into a printable

@code{language_@var{lang}} enumerated identifier into a printable

string.

string.

Update the function @code{_initialize_language} to include your

Update the function @code{_initialize_language} to include your

language.  This function picks the default language upon startup, so is

language.  This function picks the default language upon startup, so is

dependent upon which languages that GDB is built for.

dependent upon which languages that GDB is built for.

Update @code{allocate_symtab} in @file{symfile.c} and/or symbol-reading

Update @code{allocate_symtab} in @file{symfile.c} and/or symbol-reading

code so that the language of each symtab (source file) is set properly.

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.

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

Currently, the language is set based upon the extension of the source

file.  If the language can be better inferred from the symbol

file.  If the language can be better inferred from the symbol

information, please set the language of the symtab in the symbol-reading

information, please set the language of the symtab in the symbol-reading

code.

code.

Add helper code to @code{expprint.c:print_subexp()} to handle any new

Add helper code to @code{expprint.c:print_subexp()} to handle any new

expression opcodes you have added to @file{expression.h}.  Also, add the

expression opcodes you have added to @file{expression.h}.  Also, add the

printed representations of your operators to @code{op_print_tab}.

printed representations of your operators to @code{op_print_tab}.

@item Add a place of call

@item Add a place of call

Add a call to @code{@var{lang}_parse()} and @code{@var{lang}_error} in

Add a call to @code{@var{lang}_parse()} and @code{@var{lang}_error} in

@code{parse.c:parse_exp_1()}.

@code{parse.c:parse_exp_1()}.

@item Use macros to trim code

@item Use macros to trim code

The user has the option of building GDB for some or all of the

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

languages.  If the user decides to build GDB for the language

@var{lang}, then every file dependent on @file{language.h} will have the

@var{lang}, then every file dependent on @file{language.h} will have the

macro @code{_LANG_@var{lang}} defined in it.  Use @code{#ifdef}s to

macro @code{_LANG_@var{lang}} defined in it.  Use @code{#ifdef}s to

leave out large routines that the user won't need if he or she is not

leave out large routines that the user won't need if he or she is not

using your language.

using your language.

Note that you do not need to do this in your YACC parser, since if GDB

Note that you do not need to do this in your YACC parser, since if GDB

is not build for @var{lang}, then @file{@var{lang}-exp.tab.o} (the

is not build for @var{lang}, then @file{@var{lang}-exp.tab.o} (the

compiled form of your parser) is not linked into GDB at all.

compiled form of your parser) is not linked into GDB at all.

See the file @file{configure.in} for how GDB is configured for different

See the file @file{configure.in} for how GDB is configured for different

languages.

languages.

@item Edit @file{Makefile.in}

@item Edit @file{Makefile.in}

Add dependencies in @file{Makefile.in}.  Make sure you update the macro

Add dependencies in @file{Makefile.in}.  Make sure you update the macro

variables such as @code{HFILES} and @code{OBJS}, otherwise your code may

variables such as @code{HFILES} and @code{OBJS}, otherwise your code may

not get linked in, or, worse yet, it may not get @code{tar}red into the

not get linked in, or, worse yet, it may not get @code{tar}red into the

distribution!

distribution!

@end table

@end table

@node Host Definition

@node Host Definition

@chapter Host Definition

@chapter Host Definition

With the advent of autoconf, it's rarely necessary to have host

With the advent of autoconf, it's rarely necessary to have host

definition machinery anymore.

definition machinery anymore.

@section Adding a New Host

@section Adding a New Host

Most of GDB's host configuration support happens via autoconf.  It

Most of GDB's host configuration support happens via autoconf.  It

should be rare to need new host-specific definitions.  GDB still uses

should be rare to need new host-specific definitions.  GDB still uses

the host-specific definitions and files listed below, but these mostly

the host-specific definitions and files listed below, but these mostly

exist for historical reasons, and should eventually disappear.

exist for historical reasons, and should eventually disappear.

Several files control GDB's configuration for host systems:

Several files control GDB's configuration for host systems:

@table @file

@table @file

@item gdb/config/@var{arch}/@var{xyz}.mh

@item gdb/config/@var{arch}/@var{xyz}.mh

Specifies Makefile fragments needed when hosting on machine @var{xyz}.

Specifies Makefile fragments needed when hosting on machine @var{xyz}.

In particular, this lists the required machine-dependent object files,

In particular, this lists the required machine-dependent object files,

by defining @samp{XDEPFILES=@dots{}}.  Also specifies the header file

by defining @samp{XDEPFILES=@dots{}}.  Also specifies the header file

which describes host @var{xyz}, by defining @code{XM_FILE=

which describes host @var{xyz}, by defining @code{XM_FILE=

xm-@var{xyz}.h}.  You can also define @code{CC}, @code{SYSV_DEFINE},

xm-@var{xyz}.h}.  You can also define @code{CC}, @code{SYSV_DEFINE},

@code{XM_CFLAGS}, @code{XM_ADD_FILES}, @code{XM_CLIBS}, @code{XM_CDEPS},

@code{XM_CFLAGS}, @code{XM_ADD_FILES}, @code{XM_CLIBS}, @code{XM_CDEPS},

etc.; see @file{Makefile.in}.

etc.; see @file{Makefile.in}.

@item gdb/config/@var{arch}/xm-@var{xyz}.h

@item gdb/config/@var{arch}/xm-@var{xyz}.h

(@file{xm.h} is a link to this file, created by configure).  Contains C

(@file{xm.h} is a link to this file, created by configure).  Contains C

macro definitions describing the host system environment, such as byte

macro definitions describing the host system environment, such as byte

order, host C compiler and library.

order, host C compiler and library.

@item gdb/@var{xyz}-xdep.c

@item gdb/@var{xyz}-xdep.c

Contains any miscellaneous C code required for this machine as a host.

Contains any miscellaneous C code required for this machine as a host.

On most machines it doesn't exist at all.  If it does exist, put

On most machines it doesn't exist at all.  If it does exist, put

@file{@var{xyz}-xdep.o} into the @code{XDEPFILES} line in

@file{@var{xyz}-xdep.o} into the @code{XDEPFILES} line in

@file{gdb/config/@var{arch}/@var{xyz}.mh}.

@file{gdb/config/@var{arch}/@var{xyz}.mh}.

@end table

@end table

@subheading Generic Host Support Files

@subheading Generic Host Support Files

There are some ``generic'' versions of routines that can be used by

There are some ``generic'' versions of routines that can be used by

various systems.  These can be customized in various ways by macros

various systems.  These can be customized in various ways by macros

defined in your @file{xm-@var{xyz}.h} file.  If these routines work for

defined in your @file{xm-@var{xyz}.h} file.  If these routines work for

the @var{xyz} host, you can just include the generic file's name (with

the @var{xyz} host, you can just include the generic file's name (with

@samp{.o}, not @samp{.c}) in @code{XDEPFILES}.

@samp{.o}, not @samp{.c}) in @code{XDEPFILES}.

Otherwise, if your machine needs custom support routines, you will need

Otherwise, if your machine needs custom support routines, you will need

to write routines that perform the same functions as the generic file.

to write routines that perform the same functions as the generic file.

Put them into @code{@var{xyz}-xdep.c}, and put @code{@var{xyz}-xdep.o}

Put them into @code{@var{xyz}-xdep.c}, and put @code{@var{xyz}-xdep.o}

into @code{XDEPFILES}.

into @code{XDEPFILES}.

@table @file

@table @file

@item ser-unix.c

@item ser-unix.c

This contains serial line support for Unix systems.  This is always

This contains serial line support for Unix systems.  This is always

included, via the makefile variable @code{SER_HARDWIRE}; override this

included, via the makefile variable @code{SER_HARDWIRE}; override this

variable in the @file{.mh} file to avoid it.

variable in the @file{.mh} file to avoid it.

@item ser-go32.c

@item ser-go32.c

This contains serial line support for 32-bit programs running under DOS,

This contains serial line support for 32-bit programs running under DOS,

using the GO32 execution environment.

using the GO32 execution environment.

@item ser-tcp.c

@item ser-tcp.c

This contains generic TCP support using sockets.

This contains generic TCP support using sockets.

@end table

@end table

@section Host Conditionals

@section Host Conditionals

When GDB is configured and compiled, various macros are defined or left

When GDB is configured and compiled, various macros are defined or left

undefined, to control compilation based on the attributes of the host

undefined, to control compilation based on the attributes of the host

system.  These macros and their meanings (or if the meaning is not

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

documented here, then one of the source files where they are used is

indicated) are:

indicated) are:

@table @code

@table @code

@item GDBINIT_FILENAME

@item GDBINIT_FILENAME

The default name of GDB's initialization file (normally @file{.gdbinit}).

The default name of GDB's initialization file (normally @file{.gdbinit}).

@item MEM_FNS_DECLARED

@item MEM_FNS_DECLARED

Your host config file defines this if it includes declarations of

Your host config file defines this if it includes declarations of

@code{memcpy} and @code{memset}.  Define this to avoid conflicts between

@code{memcpy} and @code{memset}.  Define this to avoid conflicts between

the native include files and the declarations in @file{defs.h}.

the native include files and the declarations in @file{defs.h}.

@item NO_STD_REGS

@item NO_STD_REGS

This macro is deprecated.

This macro is deprecated.

@item NO_SYS_FILE

@item NO_SYS_FILE

Define this if your system does not have a @code{<sys/file.h>}.

Define this if your system does not have a @code{<sys/file.h>}.

@item SIGWINCH_HANDLER

@item SIGWINCH_HANDLER

If your host defines @code{SIGWINCH}, you can define this to be the name

If your host defines @code{SIGWINCH}, you can define this to be the name

of a function to be called if @code{SIGWINCH} is received.

of a function to be called if @code{SIGWINCH} is received.

@item SIGWINCH_HANDLER_BODY

@item SIGWINCH_HANDLER_BODY

Define this to expand into code that will define the function named by

Define this to expand into code that will define the function named by

the expansion of @code{SIGWINCH_HANDLER}.

the expansion of @code{SIGWINCH_HANDLER}.