\input texinfo
-@setfilename gdb.info
+@setfilename _GDBP__.info
+@c
+@c NOTE: this manual is marked up for preprocessing with a collection
+@c of m4 macros called "pretex.m4". If you see <_if__> and <_fi__>
+@c scattered around the source, you have the full source before
+@c preprocessing; if you don't, you have the source configured for
+@c _HOST__ architectures (and you can of course get the full source,
+@c with all configurations, from wherever you got this).
+_if__(0)
+
+THIS IS THE FULL SOURCE. The full source needs to be run through m4
+before either tex- or info- formatting: for example,
+ m4 pretex.m4 none.m4 m680x0.m4 as.texinfo >as-680x0.texinfo
+will produce (assuming your path finds either GNU or SysV m4; Berkeley
+won't do) a file suitable for formatting. See the text in "pretex.m4"
+for a fuller explanation (and the macro definitions).
+
+_fi__(0)
+@c
@synindex ky cp
@c FOR UPDATES LEADING TO THIS DRAFT, GDB CHANGELOG CONSULTED BETWEEN:
@c Tue Feb 26 01:47:07 1991 Cygnus John Gilmore (cygnus at yuba)
@c Sat Dec 22 02:51:40 1990 John Gilmore (gnu at cygint)
@ifinfo
-This file documents the GNU debugger GDB.
+This file documents the GNU debugger _GDBN__.
Copyright (C) 1988, 1989, 1990, 1991 Free Software Foundation, Inc.
@end ifinfo
@smallbook
@setchapternewpage odd
-@settitle Using GDB (v4.0)
+_if__(_GENERIC__)
+@settitle Using _GDBN__ (v4.0)
+_fi__(_GENERIC__)
+_if__(!_GENERIC__)
+@settitle Using _GDBN__ v4.0 (_HOST__)
+_fi__(!_GENERIC__)
@iftex
@c @finalout
@end iftex
@titlepage
-@title{Using GDB}
+@title{Using _GDBN__}
@subtitle{A Guide to the GNU Source-Level Debugger}
+_if__(!_GENERIC__)
+@subtitle{On _HOST__ Systems}
+_fi__(!_GENERIC__)
@sp 1
@c Maybe crank this up to "Fourth Edition" when released at FSF
-@c @subtitle Third Edition---GDB version 4.0
-@subtitle GDB version 4.0
+@c @subtitle Third Edition---_GDBN__ version 4.0
+@subtitle _GDBN__ version 4.0
@subtitle January 1991
@author{Richard M. Stallman}
-@author{(Revised by Roland Pesch for Cygnus Support)}
+@author{Roland H. Pesch (Cygnus Support)}
@page
@tex
@page
@node Top, New Features, (dir), (dir)
-@unnumbered Summary of GDB
+@unnumbered Summary of _GDBN__
-The purpose of a debugger such as GDB is to allow you to see what is
+The purpose of a debugger such as _GDBN__ is to allow you to see what is
going on ``inside'' another program while it executes---or what another
-program was doing at the moment it crashed. We call the other program
-``your program'' or ``the program being debugged''.
+program was doing at the moment it crashed.
-GDB can do four main kinds of things (plus other things in support of
+_GDBN__ can do four main kinds of things (plus other things in support of
these) to help you catch bugs in the act:
@enumerate
effects of one bug and go on to learn about another.
@end enumerate
-GDB can be used to debug programs written in C and C++. Pascal support
+_GDBN__ can be used to debug programs written in C and C++. Pascal support
is being implemented, and Fortran support will be added when a GNU
-Fortran compiler is written.
+Fortran compiler is ready.
@node Free Software,,,
@unnumberedsec Free Software
-GDB is Free Software, protected by the GNU General Public License (GPL).
+_GDBN__ is Free Software, protected by the GNU General Public License (GPL).
The GPL gives you the freedom to copy or adapt a licensed
program---but every person getting a copy also gets with it the
freedom to modify that copy (which means that they must get access to
For full details, @pxref{License}.
@node New Features, Invocation, Top, Top
-@unnumbered New Features in GDB version 4.0
+@unnumbered New Features in _GDBN__ version 4.0
@itemize @bullet
@item
TARGETS: Using the new command @samp{target}, you can select at runtime
whether you are debugging local files, local processes, standalone
systems over the serial port, realtime systems over a TCP/IP
-connection, etc. GDB now uses a function vector to mediate access to
+connection, etc. _GDBN__ now uses a function vector to mediate access to
all the different possible targets, making it much easier to add
support for new remote protocols.
@item
-WATCHPOINTS: GDB now sports watchpoints as well as breakpoints. You can
+WATCHPOINTS: _GDBN__ now sports watchpoints as well as breakpoints. You can
use a watchpoint to stop execution whenever the value of an expression
changes, without having to predict a particular place in the inferior
process where this may happen.
@item
-OBJECT CODE FORMATS: GDB uses a new scheme called Binary File
+OBJECT CODE FORMATS: _GDBN__ uses a new scheme called Binary File
Descriptors (BFD) to permit it to switch dynamically, without
reconfiguration or recompilation, between different object-file
formats. Formats currently supported are COFF, a.out, and the new
@item
CONFIGURATION: You must still choose a particular machine architecture
-and operating system for GDB's host and target systems when GDB is built.
+and operating system for _GDBN__'s host and target systems when _GDBN__ is built.
The script @samp{config.gdb} now handles specification of separate host
and target configurations.
@item
-INTERACTION: GDB now uses the GNU @code{readline} interface to read its
+INTERACTION: _GDBN__ now uses the GNU @code{readline} interface to read its
input; this provides inline editing of commands, using the familiar
-Emacs or VI keymaps, and command-history support. The user interface
-to GDB's control variables has been simplified and consolidated in two
+Emacs or @code{vi} keymaps, and command-history support. The user interface
+to _GDBN__'s control variables has been simplified and consolidated in two
commands, @samp{set} and @samp{show}. Output lines are now broken at
readable places, rather than overflowing onto the next line.
@item
-SOURCE LANGUAGE: GDB now understands C++ source as well as C. Multiple
+SOURCE LANGUAGE: _GDBN__ now understands C++ source as well as C. Multiple
inheritance is supported when used with G++ 2.0. There is also limited
-support for C++ exception handling: GDB can break when an exception is
+support for C++ exception handling: _GDBN__ can break when an exception is
raised, before the stack is peeled back to the exception handler's
context. You can suppress output of machine-level addresses,
displaying only source language information.
@item
-PORTS: GDB has been ported to the following new architectures:
+PORTS: _GDBN__ has been ported to the following new architectures:
AT&T 3b1, Acorn RISC machine, HP300 running HPUX, big- and little-
endian MIPS machines, Motorola 88k, Sun 386i, and Sun 3 running SunOS
4. In addition, the following are supported as targets only: AMD
29k, Intel 960, and Wind River's VxWorks.
@item
-SHARED LIBRARIES: GDB 4.0 supports SunOS shared libraries.
+SHARED LIBRARIES: _GDBN__ 4.0 supports SunOS shared libraries.
@item
WORK IN PROGRESS: kernel debugging for BSD and Mach systems; Tahoe and
@end itemize
@node Invocation, User Interface, New Features, Top
-@chapter Starting GDB
+@chapter Starting _GDBN__
-GDB is invoked with the shell command @samp{gdb}. Once started, it reads
+_GDBN__ is invoked with the shell command @samp{_GDBP__}. Once started, it reads
commands from the terminal until you tell it to exit.
-The most usual way to start GDB is with one argument or two, specifying
+The most usual way to start _GDBN__ is with one argument or two, specifying
an executable program as the argument:
@example
-gdb program
+_GDBP__ program
@end example
@noindent
or you can start with both an executable program and a core file specified:
@example
-gdb program core
+_GDBP__ program core
@end example
-You can get more detailed control over how GDB starts up using some of
+You can get more detailed control over how _GDBN__ starts up using some of
the command-line options.
All the options and command line arguments given are processed
@samp{-x} option is used.
@node File Options, Mode Options, Invocation, Invocation
-@section File-specifying Options and Arguments
+@section Options and Arguments to Choose Files
As shown above, any arguments other than options specify an executable
file and core file; that is, the first argument encountered with no
Use file @var{file} as a core dump to examine.
@item -x @var{file}
-Execute GDB commands from file @var{file}. @xref{Command Files}.
+Execute _GDBN__ commands from file @var{file}. @xref{Command Files}.
@item -d @var{directory}
Add @var{directory} to the path to search for source files.
@end table
@node Mode Options, Remote i960-Nindy, File Options, Invocation
-@section Mode Options
+@section Options to Choose Modes
@table @code
@item -nx
-Do not execute commands from the init files @file{.gdbinit}.
+Do not execute commands from the init files @file{._GDBP__init}.
Normally, the commands in these files are executed after all the
command options and arguments have been processed. @xref{Command
Files}.
@item -q
``Quiet''. Do not print the introductory and copyright messages. These
messages are also suppressed in batch mode, or if an executable file name is
-specified on the GDB command line.
+specified on the _GDBN__ command line.
@item -batch
Run in batch mode. Exit with code @code{0} after processing all the command
-files specified with @samp{-x} (and @file{.gdbinit}, if not inhibited).
-Exit with nonzero status if an error occurs in executing the GDB
+files specified with @samp{-x} (and @file{._GDBP__init}, if not inhibited).
+Exit with nonzero status if an error occurs in executing the _GDBN__
commands in the command files.
-Batch mode may be useful for running GDB as a filter, for example to
+Batch mode may be useful for running _GDBN__ as a filter, for example to
download and run a program on another computer; in order to make this
more useful, the message
@example
Program exited normally.
@end example
@noindent
-(which is ordinarily issued whenever a program running under GDB control
+(which is ordinarily issued whenever a program running under _GDBN__ control
terminates) is not issued when running in batch mode.
@item -fullname
-This option is used when Emacs runs GDB as a subprocess. It tells GDB
+This option is used when Emacs runs _GDBN__ as a subprocess. It tells _GDBN__
to output the full file name and line number in a standard,
recognizable fashion each time a stack frame is displayed (which
includes each time the program stops). This recognizable format looks
like two @samp{\032} characters, followed by the file name, line number
and character position separated by colons, and a newline. The
-Emacs-to-GDB interface program uses the two @samp{\032} characters as
+Emacs-to-_GDBN__ interface program uses the two @samp{\032} characters as
a signal to display the source code for the frame.
@item -b @var{bps}
Set the line speed (baud rate or bps) of any serial interface used by
-GDB for remote debugging.
+_GDBN__ for remote debugging.
@end table
+_if__(_I960__)
@node i960-Nindy Remote,,,
-@section GDB with a Remote Intel 960 (Nindy)
+@section _GDBN__ with a Remote Intel 960 (Nindy)
``Nindy'' is the name of a Rom Monitor program for Intel 960 target
-systems. When GDB is configured to control a remote Intel 960 using
-Nindy, you can tell GDB how to connect to the 960 in several ways:
+systems. When _GDBN__ is configured to control a remote Intel 960 using
+Nindy, you can tell _GDBN__ how to connect to the 960 in several ways:
@itemize @bullet
@item
By responding to a prompt on startup;
@item
-By using the @samp{target} command at any point during your GDB session.
+By using the @samp{target} command at any point during your _GDBN__ session.
@end itemize
+@node Nindy Startup,,,
+@subsection Startup with Nindy
+
The command-line options for Nindy are detailed below. If you simply
-start @code{gdb960} without using options to specify a serial port, you are
-prompted for it, @emph{before} you reach the ordinary GDB prompt:
+start @code{_GDBP__} without using options to specify a serial port, you are
+prompted for it, @emph{before} you reach the ordinary _GDBN__ prompt:
@example
Attach /dev/ttyNN -- specify NN, or "quit" to quit:
@end example
responding to the prompt with an empty line. If you do this, and later
wish to attach to Nindy, use @samp{target} (@pxref{Target Commands}).
-These are the startup options for beginning your GDB session with a
+@node Nindy Options,,,
+@subsection Options for Nindy
+
+These are the startup options for beginning your _GDBN__ session with a
Nindy-960 board attached:
@table @code
@item -r @var{port}
Specify the serial port name of a serial interface to be used to connect
-to the target system. This option is only available when GDB is
+to the target system. This option is only available when _GDBN__ is
configured for the Intel 960 target architecture. You may specify
@var{port} as any of: a full pathname (e.g. @samp{-r /dev/ttya}), a
device name in @samp{/dev} (e.g. @samp{-r ttya}), or simply the unique
suffix for a specific @code{tty} (e.g. @samp{-r a}).
@item -O
-(An uppercase letter ``O'', not a zero.) Specify that GDB should use
+(An uppercase letter ``O'', not a zero.) Specify that _GDBN__ should use
the ``old'' Nindy monitor protocol to connect to the target system.
-This option is only available when GDB is configured for the Intel 960
+This option is only available when _GDBN__ is configured for the Intel 960
target architecture.
@quotation
@emph{Warning:} if you specify @samp{-O}, but are actually trying to
connect to a target system using the current protocol, the connection
-will fail appearing to be a speed mismatch, and GDB will repeatedly
+will fail appearing to be a speed mismatch, and _GDBN__ will repeatedly
attempt to reconnect at several different line speeds. You can abort
this process with an interrupt.
@end quotation
@item -brk
-Specify that GDB should first send a @samp{BREAK} signal to the target
+Specify that _GDBN__ should first send a @samp{BREAK} signal to the target
system, in an attempt to reset it, before connecting to a Nindy target.
-This option is only available when GDB is configured for the Intel 960
+This option is only available when _GDBN__ is configured for the Intel 960
target architecture.
@quotation
The standard @samp{-b} option controls the line speed used on the serial
port.
+_fi__(_I960__)
-@node AMD29K Remote,,,
-@section Starting GDB with a Remote AMD 29K
+_if__(_AMD29K__)
+@node EB29K Remote,,,
+@section Starting _GDBN__ with a Remote EB29K
@cindex EB29K board
@cindex running 29K programs
@cindex 29K
-To use GDB from a Unix system to run programs on an EB29K
+To use _GDBN__ from a Unix system to run programs on AMD's EB29K
board in a PC, you must first connect a serial cable between the PC
and a serial port on the Unix system. In the following, we assume
you've hooked the cable between the PC's @samp{COM1} port and
@samp{/dev/ttya} on the Unix system.
-@node PC Comms (EB29K),,,
-@subsection PC Communications Setup
+@node Comms (EB29K),,,
+@subsection Communications Setup
The next step is to set up the PC's port, by doing something like the
following in DOS on the PC:
@example
the command @samp{CTTY con}---but you must send it over the device that
had control, in our example over the @samp{com1} serial line).
-@node Unix Comms (EB29K),,,
-@subsection Unix Communications Setup
From the Unix host, use a communications program such as @code{tip} or
@code{cu} to communicate with the PC; for example,
@example
@c stdout redirected... is it worth experimenting? Maybe if the literal
@c combinations of things typed here don't work? ---pesch@cygnus.com, 25feb91
-@node EBMON,,,
-@subsection Using EBMON
@kindex EBMON
Using the @samp{tip} or @samp{cu} connection, change the DOS working
directory to the directory containing a copy of your 29K program, then
@example
C> CD g:\usr\joe\work29k
C> EBMON
-@end example
@c FIXME: insert EBMON banner display here. ---pesch@cygnus.com, 25feb91
+C> ~.
+@end example
-Then close the @code{cu} or @code{tip} connection (by typing @samp{~.}
-for example). @code{EBMON} will keep running, ready for GDB to take
-over.
+Then exit the @code{cu} or @code{tip} program (done in the example by
+typing @code{~.}). @code{EBMON} will keep running, ready for _GDBN__ to
+take over.
-@node 29K Program,,,
-@subsection Your 29K Program
For this example, we've assumed what is probably the most convenient
way to make sure the same 29K program is on both the PC and the Unix
system: a PC/NFS connection that establishes ``drive'' @code{g:} on the
PC as a file system on the Unix host. If you don't have PC/NFS or
something similar connecting the two systems, you must arrange some
other way---perhaps floppy-disk transfer---of getting the 29K program
-from the Unix system to the PC; GDB will @emph{not} download it over the
+from the Unix system to the PC; _GDBN__ will @emph{not} download it over the
serial line.
-@node gdb-EB29K
+@node _GDBP__-EB29K
@subsection EB29K cross-debugging
Finally, @code{cd} to the directory containing an image of your 29K
-program on the Unix system, and start GDB---specifying as argument the
+program on the Unix system, and start _GDBN__---specifying as argument the
name of your 29K program:
@example
cd /usr/joe/work29k
-gdb myfoo
+_GDBP__ myfoo
@end example
Now you can use the @code{target} command:
@example
the name on the Unix side.
At this point, you can set any breakpoints you wish; when you're ready
-to see your program run on the 29K board, use the GDB command
+to see your program run on the 29K board, use the _GDBN__ command
@example
run
@end example
-To stop debugging the remote program, use the GDB @samp{detach}
+To stop debugging the remote program, use the _GDBN__ @samp{detach}
command.
To return control of the PC to its console, use @code{tip} or @code{cu}
-once again, after your GDB session has concluded, to attach to
+once again, after your _GDBN__ session has concluded, to attach to
@code{EBMON}. You can then type the command @samp{q} to shut down
@code{EBMON}, returning control to the DOS command-line interpreter.
Type @samp{CTTY con} to return command input to the main DOS console,
@subsection Remote Log
@kindex eb.log
@cindex log file for EB29K
-The GDB @code{target amd-eb} command creates a file @file{eb.log} in the
+The @samp{target amd-eb} command creates a file @file{eb.log} in the
current working directory, to help debug problems with the connection.
@file{eb.log} records all the output from @code{EBMON}, including echoes
of the commands sent to it. Running @samp{tail -f} on this file in
another window often helps to debug trouble with @code{EBMON}, or
unexpected events on the PC side of the connection.
+_fi__(_AMD29K__)
@node User Interface, Files, Invocation, Top
-@chapter GDB Commands and Displays
+@chapter _GDBN__ Commands and Displays
-A GDB command is a single line of input. There is no limit on how long
+A _GDBN__ command is a single line of input. There is no limit on how long
it can be. It starts with a command name, which is followed by arguments
whose meaning depends on the command name. For example, the command
@samp{step} accepts an argument which is the number of times to step,
no arguments. Some command names do not allow any arguments.
@cindex abbreviation
-GDB command names may always be truncated if that abbreviation is
+_GDBN__ command names may always be truncated if that abbreviation is
unambiguous. Other possible command abbreviations are listed in the
documentation of the individual commands. Sometimes even ambiguous
abbreviations are allowed; for example, @samp{s} is specially defined as
names start with @samp{s}.
@cindex repeating commands
-A blank line as input to GDB means to repeat the previous command.
+A blank line as input to _GDBN__ means to repeat the previous command.
Certain commands will not repeat this way; these are commands for which
unintentional repetition might cause trouble and which you are unlikely
to want to repeat. Certain others (@samp{list} and @samp{x}) act
@item help
@itemx help @var{category}
@itemx help @var{command}
-You can always ask GDB itself for information on its commands, using the
+You can always ask _GDBN__ itself for information on its commands, using the
command @samp{help}. With a command name as argument, it will display a
paragraph on how to use the command. Used with no arguments,
@samp{help} displays a short list of named categories of commands; you
@kindex info version
@item info version
-As GDB evolves, new commands are introduced, and old ones may wither
-away. If multiple versions of GDB are in use at your site, it may
-occasionally be useful to make sure what version of GDB you're running.
-GDB announces its version whenever it starts up; but you can make it
+As _GDBN__ evolves, new commands are introduced, and old ones may wither
+away. If multiple versions of _GDBN__ are in use at your site, it may
+occasionally be useful to make sure what version of _GDBN__ you're running.
+_GDBN__ announces its version whenever it starts up; but you can make it
repeat this information with the @samp{info version} command.
@end table
@cindex prompt
-GDB indicates its readiness to read a command by printing a string
-called the @dfn{prompt}. This string is normally @samp{(gdb)}. You can
+_GDBN__ indicates its readiness to read a command by printing a string
+called the @dfn{prompt}. This string is normally @samp{(_GDBP__)}. You can
change the prompt string with the @samp{set prompt} command. For
-instance, when debugging GDB with GDB, it is useful to change the prompt
-in one of the GDBs so that you tell which one you are talking to.
+instance, when debugging _GDBN__ with _GDBN__, it is useful to change the prompt
+in one of the _GDBN__s so that you tell which one you are talking to.
@table @code
@item set prompt @var{newprompt}
@kindex set prompt
-Directs GDB to use @var{newprompt} as its prompt string henceforth.
+Directs _GDBN__ to use @var{newprompt} as its prompt string henceforth.
@kindex show prompt
@item show prompt
Prints a line of the form: @samp{Gdb's prompt is: @var{your-prompt}}
@end table
-@cindex exiting GDB
+@cindex exiting _GDBN__
@kindex quit
-To exit GDB, use the @samp{quit} command (abbreviated @samp{q}), or type
+To exit _GDBN__, use the @samp{quit} command (abbreviated @samp{q}), or type
an end-of-file character (usually @ctrl{d}). An interrupt (often
-@ctrl{c}) will not exit from GDB, but rather will terminate the action
-of any GDB command that is in progress and return to GDB command level.
-It is safe to type the interrupt character at any time because GDB does
+@ctrl{c}) will not exit from _GDBN__, but rather will terminate the action
+of any _GDBN__ command that is in progress and return to _GDBN__ command level.
+It is safe to type the interrupt character at any time because _GDBN__ does
not allow it to take effect until a time when it is safe.
@cindex readline
@cindex command line editing
@cindex history substitution
-GDB reads its input commands via the @code{readline} interface. This
+_GDBN__ reads its input commands via the @code{readline} interface. This
GNU library provides consistent behavior for programs which provide a
command line interface to the user. Advantages are @samp{emacs}-style
or @samp{vi}-style inline editing of commands, @samp{csh}-like history
substitution, and a storage and recall of command history across
debugging sessions.
-You may control the behavior of command line editing in GDB with the
+You may control the behavior of command line editing in _GDBN__ with the
command @samp{set}. You may check the status of any of these settings
with the command @samp{show}.
@cindex history file
@kindex set history file
@item set history file @var{filename}
-Set the name of the GDB command history file to @samp{filename}. This is
-the file from which GDB will read an initial command history
+Set the name of the _GDBN__ command history file to @samp{filename}. This is
+the file from which _GDBN__ will read an initial command history
list or to which it will write this list when it exits. This list is
accessed through history expansion or through the history
command editing characters listed below. This file defaults to the
@kindex set history write
@item set history write
@itemx set history write on
-Make GDB record command history in a file, whose name may be specified with the
+Make _GDBN__ record command history in a file, whose name may be specified with the
@samp{set history file} command. By default, this option is disabled.
@item set history write off
-Make GDB stop recording command history in a file.
+Make _GDBN__ stop recording command history in a file.
@cindex history size
@kindex set history size
@item set history size @var{size}
-Set the number of commands which GDB will keep in its history list.
+Set the number of commands which _GDBN__ will keep in its history list.
This defaults to the value of the environmental variable
@code{HISTSIZE}, or to 256 if this variable is not set.
@end table
@itemx show history write
@itemx show history size
@itemx show history expansion
-These commands display the state of the GDB history parameters.
+These commands display the state of the _GDBN__ history parameters.
@samp{show history} by itself displays all four states.
@kindex show
@kindex info set
@item show
@itemx info set
-This chapter introduces a number of internal GDB variables that you
+This chapter introduces a number of internal _GDBN__ variables that you
can control with the @samp{set} command, and display with the
@samp{show} command. A number of others are introduced throughout the
manual. To display all the settable parameters and their current
@end table
-Occasionally it is useful to execute a shell command from within GDB.
+Occasionally it is useful to execute a shell command from within _GDBN__.
This can be done with the @samp{shell} command.
@table @code
@item shell @var{command string}
@kindex shell
@cindex shell escape
-Directs GDB to invoke an inferior shell to execute @var{command string}.
-The environment variable @code{SHELL} is used if it exists, otherwise GDB
+Directs _GDBN__ to invoke an inferior shell to execute @var{command string}.
+The environment variable @code{SHELL} is used if it exists, otherwise _GDBN__
uses @samp{/bin/sh}.
@end table
The utility @samp{make} is often needed in development environments.
-You don't have to use the @samp{shell} command for this purpose in GDB:
+You don't have to use the @samp{shell} command for this purpose in _GDBN__:
@table @code
@item make @dots{}
@kindex make
@cindex calling make
-Causes GDB to execute an inferior @code{make} program with the specified
+Causes _GDBN__ to execute an inferior @code{make} program with the specified
arguments. This is equivalent to @samp{shell make @dots{}}.
@end table
@cindex screen size
@cindex pauses in output
-Certain commands to GDB may produce large amounts of information output
-to the screen. To help you read all of it, GDB pauses and asks you for
+Certain commands to _GDBN__ may produce large amounts of information output
+to the screen. To help you read all of it, _GDBN__ pauses and asks you for
input at the end of each page of output. Type @key{RET} when you want
-to continue the output. Normally GDB knows the size of the screen from
+to continue the output. Normally _GDBN__ knows the size of the screen from
the termcap data base together with the value of the @code{TERM}
environment variable and the @code{stty rows} and @code{stty cols}
settings. If this is not correct, you can override it with
the @samp{set screen-height} and @samp{set screen-width} commands:
-GDB also uses the screen width setting to determine when to wrap lines
+_GDBN__ also uses the screen width setting to determine when to wrap lines
of output. Depending what is being printed, it tries to break the
line at a readable place, rather than simply letting it overflow onto
the following line.
a screen width of @var{cpl} characters. The associated @samp{show}
commands display the current settings.
-If you specify a height of zero lines, GDB will not pause during output
+If you specify a height of zero lines, _GDBN__ will not pause during output
no matter how long the output is. This is useful if output is to a file
or to an editor buffer.
@end table
@cindex number representation
@cindex entering numbers
-You can always enter numbers in octal, decimal, or hexadecimal in GDB by
+You can always enter numbers in octal, decimal, or hexadecimal in _GDBN__ by
the usual conventions: octal numbers begin with @samp{0}, decimal
numbers end with @samp{.}, and hexadecimal numbers begin with @samp{0x}.
Numbers that begin with none of these are, by default, entered in base
@end table
-By default, GDB is silent about its inner workings. If you are running
+By default, _GDBN__ is silent about its inner workings. If you are running
on a slow machine, you may want to use the @samp{set verbose} command.
-It will make GDB tell you when it does a lengthy internal operation, so
+It will make _GDBN__ tell you when it does a lengthy internal operation, so
you won't think it has crashed.
Currently, the messages controlled by @samp{set verbose} are those which
@table @code
@kindex set verbose
@item set verbose on
-Enables GDB's output of certain informational messages.
+Enables _GDBN__'s output of certain informational messages.
@item set verbose off
-Disables GDB's output of certain informational messages.
+Disables _GDBN__'s output of certain informational messages.
@kindex show verbose
@item show verbose
Displays whether @samp{set verbose} is on or off.
@end table
-By default, if GDB encounters bugs in the symbol table of an object file,
+By default, if _GDBN__ encounters bugs in the symbol table of an object file,
it prints a single message about each type of problem it finds, then
shuts up. You can suppress these messages, or allow more than one such
message to be printed if you want to see how frequent the problems are.
@table @code
@kindex set complaints
@item set complaints @var{limit}
-Permits GDB to output @var{limit} complaints about each type of unusual
+Permits _GDBN__ to output @var{limit} complaints about each type of unusual
symbols before becoming silent about the problem. Set @var{limit} to
zero to suppress all complaints; set it to a large number to prevent
complaints from being suppressed.
@kindex show complaints
@item show complaints
-Displays how many symbol complaints GDB is permitted to produce.
+Displays how many symbol complaints _GDBN__ is permitted to produce.
@end table
-By default, GDB is cautious, and asks what sometimes seem to be a lot of
+By default, _GDBN__ is cautious, and asks what sometimes seem to be a lot of
stupid questions. For example, if you try to run a program which is
already running:
@example
-(gdb) run
+(_GDBP__) run
The program being debugged has been started already.
Start it from the beginning? (y or n)
@end example
@end table
@node Files, Compilation, User Interface, Top
-@chapter Specifying GDB's Files
+@chapter Specifying _GDBN__'s Files
@cindex core dump file
@cindex executable file
@cindex symbol table
-GDB needs to know the file name of the program to be debugged, both in
+_GDBN__ needs to know the file name of the program to be debugged, both in
order to read its symbol table and in order to start the program. To
-debug a core dump of a previous run, GDB must be told the file name of
+debug a core dump of a previous run, _GDBN__ must be told the file name of
the core dump.
The usual way to specify the executable and core dump file names is with
-the command arguments given when you start GDB, as discussed in
+the command arguments given when you start _GDBN__, as discussed in
@pxref{Invocation}.
But occasionally it is necessary to change to a different file during a
-GDB session. Or you may run GDB and forget to specify the files you
-want to use. In these situations the GDB commands to specify new files
+_GDBN__ session. Or you may run _GDBN__ and forget to specify the files you
+want to use. In these situations the _GDBN__ commands to specify new files
are useful.
@table @code
Use @var{filename} as the program to be debugged. It is read for its
symbols, for getting the contents of pure memory, and it is the program
executed when you use the @samp{run} command. If you do not specify a
-directory and the file is not found in GDB's working directory, GDB will
+directory and the file is not found in _GDBN__'s working directory, _GDBN__ will
use the environment variable @code{PATH} as a list of directories to
search, just as the shell does when looking for a program to run.
@item exec-file @var{filename}
@kindex exec-file
Specify that the program to be run (but not the symbol table) is found
-in @var{filename}. GDB will search the environment variable @code{PATH}
+in @var{filename}. _GDBN__ will search the environment variable @code{PATH}
if necessary to locate the program.
@item symbol-file @var{filename}
searched when necessary. Use the @samp{file} command to get both symbol
table and program to run from the same file.
-@samp{symbol-file} with no argument clears out GDB's information on your
+@samp{symbol-file} with no argument clears out _GDBN__'s information on your
program's symbol table.
-The @samp{symbol-file} command causes GDB to forget the contents of its
+The @samp{symbol-file} command causes _GDBN__ to forget the contents of its
convenience variables, the value history, and all breakpoints and
auto-display expressions. This is because they may contain pointers to
the internal data recording symbols and data types, which are part of
-the old symbol table data being discarded inside GDB.
+the old symbol table data being discarded inside _GDBN__.
On some kinds of object files, the @samp{symbol-file} command does not
actually read the symbol table in full right away. Instead, it scans
are present. The details are read later, one source file at a time,
when they are needed.
-The purpose of this two-stage reading strategy is to make GDB start up
+The purpose of this two-stage reading strategy is to make _GDBN__ start up
faster. For the most part, it is invisible except for occasional pauses
while the symbol table details for a particular source file are being
read. (The @samp{set verbose} command can turn these pauses into
read the symbol table data in full right away. We haven't implemented
the two-stage strategy for COFF yet.
-When GDB is configured for a particular environment, it will understand
+When _GDBN__ is configured for a particular environment, it will understand
debugging information in whatever format is the standard generated for
-that environment; you may use either the GNU compiler GCC, or other
+that environment; you may use either the GNU compiler _GCC__, or other
compilers that adhere to the local conventions. Best results are
-usually obtained from GCC; for example, using GCC you can generate
+usually obtained from _GCC__; for example, using _GCC__ you can generate
debugging information for optimized code.
-While the symbol file is being read, GDB will occasionally encounter
+While the symbol file is being read, _GDBN__ will occasionally encounter
problems, such as symbol types it does not recognize, or known bugs in
compiler output. By default, it prints one message about each such
type of problem, no matter how many times the problem occurs. You can
The symbol information shows where symbol scopes begin and end
(such as at the start of a function or a block of statements). This
error indicates that an inner scope block is not fully contained
-in its outer scope blocks. GDB circumvents the problem by treating
+in its outer scope blocks. _GDBN__ circumvents the problem by treating
the inner block as if it had the same scope as the outer block.
@var{symbol} may be ``(don't know)'' if the outer block is not
a function.
The symbol information for symbol scope blocks should occur in
order of increasing addresses. This error indicates that it does not
-do so. GDB does not circumvent this problem, and will have trouble
+do so. _GDBN__ does not circumvent this problem, and will have trouble
locating symbols in the source file whose symbols being read. (You
can often determine what source file is affected by turning on
@samp{info verbose}. @xref{User Interface}.)
The symbol information for a symbol scope block has a start address
smaller than the address of the preceding source line. This is known
-to occur in the SunOS 4.1.1 (and earlier) C compiler. GDB circumvents
+to occur in the SunOS 4.1.1 (and earlier) C compiler. _GDBN__ circumvents
the problem by treating the symbol scope block as starting on the
previous source line.
@comment @item{encountered DBX-style class variable debugging information.
@comment You seem to have compiled your program with "g++ -g0" instead of "g++ -g".
-@comment Therefore GDB will not know about your class variables}
+@comment Therefore _GDBN__ will not know about your class variables}
@comment
@comment This error indicates that the symbol information produced for a C++
@comment program includes zero-size fields, which indicated static fields in
@item bad string table offset in symbol @var{n}
Symbol number @var{n} contains a pointer into the string table which is
-larger than the size of the string table. GDB circumvents the problem
+larger than the size of the string table. _GDBN__ circumvents the problem
by considering the symbol to have the name @code{foo}, which may cause
other problems if many symbols end up with this name. @cindex{foo}
@item unknown symbol type @code{0xNN}
-The symbol information contains new data types that GDB does not yet
+The symbol information contains new data types that _GDBN__ does not yet
know how to read. @code{0xNN} is the symbol type of the misunderstood
-information, in hexadecimal. GDB circumvents the error by ignoring
+information, in hexadecimal. _GDBN__ circumvents the error by ignoring
this symbol information. This will usually allow the program to be
debugged, though certain symbols will not be accessible. If you
-encounter such a problem and feel like debugging it, you can debug gdb
+encounter such a problem and feel like debugging it, you can debug _GDBP__
with itself, breakpoint on "complain", then go "up" to
read_dbx_symtab() and examine *bufp to see the symbol.
@kindex core-file
Specify the whereabouts of a core dump file to be used as the ``contents
of memory''. Traditionally, core files contain only some parts of the
-address space of the process that generated them; GDB can access the
+address space of the process that generated them; _GDBN__ can access the
executable file itself for other parts.
@samp{core-file} with no argument specifies that no core file is
to be used.
Note that the core file is ignored when your program is actually running
-under GDB. So, if you have been running the program and you wish to
+under _GDBN__. So, if you have been running the program and you wish to
debug a core file instead, you must kill the subprocess in which the
program is running. To do this, use the @samp{kill} command
(@pxref{Kill Process}).
from the file @var{filename}. You would use this command when that file
has been dynamically loaded (by some other means) into the program that
is running. @var{address} should be the memory address at which the
-file has been loaded; GDB cannot figure this out for itself.
+file has been loaded; _GDBN__ cannot figure this out for itself.
The symbol table of the file @var{filename} is added to the symbol table
originally read with the @samp{symbol-file} command. You can use the
@samp{add-syms} command any number of times; the new symbol data thus
read keeps adding to the old. The @samp{symbol-file} command forgets
-all the symbol data GDB has read.
+all the symbol data _GDBN__ has read.
@item info files
@itemx info target
@kindex info target
@samp{info files} and @samp{info target} are synonymous; both print the
current targets (@pxref{Targets}), including the names of the
-executable and core dump files currently in use by GDB, and the files
+executable and core dump files currently in use by _GDBN__, and the files
from which symbols were loaded.
Beware: the similar command @samp{info targets} lists all possible
@end table
While all three file-specifying commands allow both absolute and relative
-file names as arguments, GDB always converts the file name to an absolute
+file names as arguments, _GDBN__ always converts the file name to an absolute
one and remembers it that way.
@kindex sharedlibrary
@kindex share
@cindex shared libraries
-GDB supports the SunOS shared library format. Symbols from a shared
+_GDBN__ supports the SunOS shared library format. Symbols from a shared
library cannot be referenced before the shared library has been linked
with the program. (That is to say, after one types @samp{run} and
the function @code{main()} has been entered; or when examining core
Some things do not work as well with @samp{-g -O} as with just
@samp{-g}, particularly on machines with instruction scheduling. If in
doubt, recompile with @samp{-g} alone, and if this fixes the problem,
-please report it as a bug (including a test case---@pxref{GDB Bugs}).
+please report it as a bug (including a test case---@pxref{_GDBN__ Bugs}).
-Older versions of the GNU C compiler, GCC, permitted a variant option
-@samp{-gg} for debugging information. GDB no longer supports this format;
+Older versions of the GNU C compiler, _GCC__, permitted a variant option
+@samp{-gg} for debugging information. _GDBN__ no longer supports this format;
if your GNU C compiler has this option, do not use it.
@ignore
-@comment As far as I know, there are no cases in which GDB will
+@comment As far as I know, there are no cases in which _GDBN__ will
@comment produce strange output in this case. (but no promises).
If your program includes archives made with the @code{ar} program, and
if the object files used as input to @code{ar} were compiled without the
-@samp{-g} option and have names longer than 15 characters, GDB will get
+@samp{-g} option and have names longer than 15 characters, _GDBN__ will get
confused reading the program's symbol table. No error message will be
-given, but GDB may behave strangely. The reason for this problem is a
+given, but _GDBN__ may behave strangely. The reason for this problem is a
deficiency in the Unix archive file format, which cannot represent file
names longer than 15 characters.
A @dfn{target} is an interface between the debugger and a particular
kind of file or process.
-Often, you will be able to run GDB in the same host environment as the
+Often, you will be able to run _GDBN__ in the same host environment as the
program you are debugging; in that case, the debugging target can just be
specified as a side effect of the @samp{file} or @samp{core} commands.
-When you need more flexibility---for example, running GDB on a
+When you need more flexibility---for example, running _GDBN__ on a
physically separate host, controlling standalone systems over a
serial port, or realtime systems over a TCP/IP connection---you can use
the @samp{target} command.
without abandoning your work on a core file.
More than one target can potentially respond to a request. In
-particular, when you access memory GDB will walk down the three strata of
+particular, when you access memory _GDBN__ will walk down the three strata of
targets until it finds a target that can handle that particular address.
Strata are always examined in a fixed order: first a process if there is
@table @code
@item target @var{type} @var{parameters}
-Connects the GDB host environment to a target machine or process. A
+Connects the _GDBN__ host environment to a target machine or process. A
target is typically a protocol for talking to debugging facilities. You
use the argument @var{type} to specify the type or protocol of the
target machine; for example, @samp{target vxworks} for a TCP/IP link to
@samp{info target} (@pxref{Files}).
@end table
-Here are some common targets (available, or not, depending on GDB
+Here are some common targets (available, or not, depending on _GDBN__
configuration):
@table @code
@item target remote @var{dev}
@kindex target remote
-Remote serial target in gdb-specific protocol. The argument @var{dev}
+Remote serial target in _GDBP__-specific protocol. The argument @var{dev}
specifies what serial device to use for the connection (e.g.
@code{/dev/ttya}).
+_if__(_AMD29K__)
@item target amd-eb @var{dev} @var{speed} @var{PROG}
@kindex target amd-eb
@cindex AMD EB29K
name of the program to be debugged, as it appears to DOS on the PC.
@xref{AMD29K Remote}.
+_fi__(_AMD29K__)
+_if__(_I960__)
@item target nindy @var{devicename}
@kindex target nindy
An Intel 960 board controlled by a Nindy Monitor. @var{devicename} is
the name of the serial device to use for the connection, e.g.
@samp{/dev/ttya}.
+_fi__(_I960__)
+_if__(_VXWORKS__)
@item target vxworks @var{machinename}
@kindex target vxworks
A VxWorks system, attached via TCP/IP. The argument @var{machinename}
is the target system's machine name or IP address.
+_fi__(_VXWORKS__)
@end table
-Different targets are available on different configurations of GDB; your
+_if__(_GENERIC__)
+Different targets are available on different configurations of _GDBN__; your
configuration may have more or fewer targets.
+_fi__(_GENERIC__)
@node Running, Stopping, Targets, Top
-@chapter Running Programs Under GDB
+@chapter Running Programs Under _GDBN__
@cindex running
@kindex run
-To start your program under GDB, use the @samp{run} command. Except on
+To start your program under _GDBN__, use the @samp{run} command. Except on
VxWorks, the program must already have been specified using the
-@samp{file} or @samp{exec-file} command, or with an argument to GDB
+@samp{file} or @samp{exec-file} command, or with an argument to _GDBN__
(@pxref{Files}).
On targets that support processes, @samp{run} creates an inferior
program.
The execution of a program is affected by certain information it
-receives from its superior. GDB provides ways to specify this
+receives from its superior. _GDBN__ provides ways to specify this
information, which you must do @i{before} starting the program. (You
can change it after starting the program, but such changes do not affect
the program unless you start it over again.) This information may be
is used with the @code{SHELL} environment variable.
@item The @i{environment.}
-The program normally inherits its environment from GDB, but you can
-use the GDB commands @samp{set environment} and
+The program normally inherits its environment from _GDBN__, but you can
+use the _GDBN__ commands @samp{set environment} and
@samp{unset environment} to change parts of the environment that will
be given to the program.@refill
@item The @i{working directory.}
-The program inherits its working directory from GDB. You can set GDB's
-working directory with the @samp{cd} command in GDB.
+The program inherits its working directory from _GDBN__. You can set _GDBN__'s
+working directory with the @samp{cd} command in _GDBN__.
@end table
When you issue the @samp{run} command, your program begins to execute
inferior, using the @samp{print} or @samp{call} commands. @xref{Data}.
If the modification time of your symbol file has changed since the last
-time GDB read its symbols, GDB will discard its symbol table and re-read
+time _GDBN__ read its symbols, _GDBN__ will discard its symbol table and re-read
it. In this process, it tries to retain your current breakpoints.
@menu
* Working Directory:: Specifying the working directory for giving
to your program when it is run.
* Input/Output:: Specifying the program's standard input and output.
-* Attach:: Debugging a process started outside GDB.
+* Attach:: Debugging a process started outside _GDBN__.
* Kill Process:: Getting rid of the child process running your program.
@end menu
@itemx set environment @var{varname} = @var{value}
@kindex set environment
Sets environment variable @var{varname} to @var{value}, for your program
-only, not for GDB itself. @var{value} may be any string; the values of
+only, not for _GDBN__ itself. @var{value} may be any string; the values of
environment variables are just strings, and any interpretation is
supplied by your program itself. The @var{value} parameter is optional;
if it is eliminated, the variable is set to a null value.
@cindex working directory (of your program)
Each time you start your program with @samp{run}, it inherits its
-working directory from the current working directory of GDB. GDB's
+working directory from the current working directory of _GDBN__. _GDBN__'s
working directory is initially whatever it inherited from its parent
process (typically the shell), but you can specify a new working
-directory in GDB with the @samp{cd} command.
+directory in _GDBN__ with the @samp{cd} command.
-The GDB working directory also serves as a default for the commands
-that specify files for GDB to operate on. @xref{Files}.
+The _GDBN__ working directory also serves as a default for the commands
+that specify files for _GDBN__ to operate on. @xref{Files}.
@table @code
@item cd @var{directory}
@kindex cd
-Set GDB's working directory to @var{directory}.
+Set _GDBN__'s working directory to @var{directory}.
@item pwd
@kindex pwd
-Print GDB's working directory.
+Print _GDBN__'s working directory.
@end table
@node Input/Output, Attach, Working Directory, Running
@cindex i/o
@cindex terminal
@cindex controlling terminal
-By default, the program you run under GDB does input and output to the same
-terminal that GDB uses.
+By default, the program you run under _GDBN__ does input and output to the same
+terminal that _GDBN__ uses.
You can redirect the program's input and/or output using @samp{sh}-style
redirection commands in the @samp{run} command. For example,
When you use the @samp{tty} command or redirect input in the @samp{run}
command, only the @emph{input for your program} is affected. The input
-for GDB still comes from your terminal.
+for _GDBN__ still comes from your terminal.
@node Attach, Kill Process, Input/Output, Running
@section Debugging an Already-Running Process
targets). The command takes as argument a process ID.
You specify a process ID to debug an already-running process that was
-started outside of GDB. (The usual way to find out the process-id of
+started outside of _GDBN__. (The usual way to find out the process-id of
a Unix process is with the @code{ps} utility, or with the @code{jobs -l}
shell command.) In this case, you must have permission to send the
process a signal, and it must have the same effective user ID as the
When using @samp{attach}, you should first use the @samp{file} command
to specify the program running in the process and load its symbol table.
-The first thing GDB does after arranging to debug the process is to stop
-it. You can examine and modify an attached process with all the GDB
+The first thing _GDBN__ does after arranging to debug the process is to stop
+it. You can examine and modify an attached process with all the _GDBN__
commands that ordinarily available when you start processes with
@samp{run}. You can insert breakpoints; you can step and continue; you
can modify storage. If you would rather the process continue running,
-you may use the @samp{continue} command after attaching GDB to the
+you may use the @samp{continue} command after attaching _GDBN__ to the
process.
@kindex detach
When you have finished debugging the attached process, you can use the
-@samp{detach} command to release it from GDB's control. Detaching
+@samp{detach} command to release it from _GDBN__'s control. Detaching
the process continues its execution. After the @samp{detach} command,
-that process and GDB become completely independent once more, and you
+that process and _GDBN__ become completely independent once more, and you
are ready to @samp{attach} another process or start one with @samp{run}.
-If you exit GDB or use the @samp{run} command while you have an attached
+If you exit _GDBN__ or use the @samp{run} command while you have an attached
process, you kill that process. By default, you will be asked for
confirmation if you try to do either of these things; you can control
whether or not this happens by using the @samp{set caution} command
@table @code
@item kill
@kindex kill
-Kill the child process in which your program is running under GDB.
+Kill the child process in which your program is running under _GDBN__.
@end table
-This command is useful if you wish to debug a core dump instead. GDB
+This command is useful if you wish to debug a core dump instead. _GDBN__
ignores any core dump file if it is actually running the program.
On some operating systems, you can't execute your program in another
-process while breakpoints are active inside GDB. The @samp{kill}
+process while breakpoints are active inside _GDBN__. The @samp{kill}
command is also useful in this situation, if you wish to run the program
outside the debugger.
The @samp{kill} command is also useful if you wish to recompile and
relink the program, since on many systems it is impossible to modify an
executable file which is running in a process. In this case, when you
-next type @samp{run}, GDB will notice that the file has changed, and
+next type @samp{run}, _GDBN__ will notice that the file has changed, and
will re-read the symbol table (while trying to preserve your current
breakpoint settings).
@menu
* Signals:: Fatal signals in your program just stop it;
- then you can use GDB to see what is going on.
+ then you can use _GDBN__ to see what is going on.
* Breakpoints:: Breakpoints let you stop your program when it
reaches a specified point in the code.
an expression changes.
@code{SIGINT} does not indicate an error in the program, but it is normally
fatal so it can carry out the purpose of @kbd{Ctrl-c}: to kill the program.
-GDB has the ability to detect any occurrence of a signal in the program
-running under GDB's control. You can tell GDB in advance what to do for
+_GDBN__ has the ability to detect any occurrence of a signal in the program
+running under _GDBN__'s control. You can tell _GDBN__ in advance what to do for
each kind of signal.
@cindex handling signals
-Normally, GDB is set up to ignore non-erroneous signals like @code{SIGALRM}
+Normally, _GDBN__ is set up to ignore non-erroneous signals like @code{SIGALRM}
(so as not to interfere with their role in the functioning of the program)
but to stop the program immediately whenever an error signal happens.
You can change these settings with the @samp{handle} command.
@table @code
@item info signal
@kindex info signal
-Print a table of all the kinds of signals and how GDB has been told to
+Print a table of all the kinds of signals and how _GDBN__ has been told to
handle each one. You can use this to see the signal numbers of all
the defined types of signals.
@item handle @var{signal} @var{keywords}@dots{}
@kindex handle
-Change the way GDB handles signal @var{signal}. @var{signal} can be the
+Change the way _GDBN__ handles signal @var{signal}. @var{signal} can be the
number of a signal or its name (with or without the @samp{SIG} at the
beginning). The @var{keywords} say what change to make.
@end table
@table @code
@item nostop
-GDB should not stop the program when this signal happens. It may
+_GDBN__ should not stop the program when this signal happens. It may
still print a message telling you that the signal has come in.
@item stop
-GDB should stop the program when this signal happens. This implies
+_GDBN__ should stop the program when this signal happens. This implies
the @samp{print} keyword as well.
@item print
-GDB should print a message when this signal happens.
+_GDBN__ should print a message when this signal happens.
@item noprint
-GDB should not mention the occurrence of the signal at all. This
+_GDBN__ should not mention the occurrence of the signal at all. This
implies the @samp{nostop} keyword as well.
@item pass
-GDB should allow the program to see this signal; the program will be
+_GDBN__ should allow the program to see this signal; the program will be
able to handle the signal, or may be terminated if the signal is fatal
and not handled.
@item nopass
-GDB should not allow the program to see this signal.
+_GDBN__ should not allow the program to see this signal.
@end table
When a signal has been set to stop the program, the program cannot see the
signal until you continue. It will see the signal then, if @samp{pass} is
in effect for the signal in question @i{at that time}. In other words,
-after GDB reports a signal, you can use the @samp{handle} command with
+after _GDBN__ reports a signal, you can use the @samp{handle} command with
@samp{pass} or @samp{nopass} to control whether that signal will be seen by
the program when you later continue it.
@cindex breakpoints
A @dfn{breakpoint} makes your program stop whenever a certain point in the
-program is reached. You set breakpoints explicitly with GDB commands,
+program is reached. You set breakpoints explicitly with _GDBN__ commands,
specifying the place where the program should stop by line number, function
name or exact address in the program. You can add various other conditions
to control whether the program will stop.
other breakpoints, but this can well be worth it to catch errors where
you have no clue what part of your program is the culprit. Some
processors provide special hardware to implement this feature; future
-releases of GDB will use such hardware if it is available.
+releases of _GDBN__ will use such hardware if it is available.
@end table
@menu
* Set Breaks:: How to establish breakpoints.
-* Exception Handling:: How GDB supports exception handling for C++.
+* Exception Handling:: How _GDBN__ supports exception handling for C++.
* Delete Breaks:: How to remove breakpoints no longer needed.
* Disabling:: How to disable breakpoints (turn them off temporarily).
* Conditions:: Making extra conditions on whether to stop.
stack frame (@pxref{Stack}). In any selected frame but the innermost,
this will cause the program to stop as soon as control returns to that
frame. This is equivalent to a @samp{finish} command in the frame
-inside the selected frame. If this is done in the innermost frame, GDB
+inside the selected frame. If this is done in the innermost frame, _GDBN__
will stop the next time it reaches the current location; this may be
useful inside of loops.
-GDB normally ignores breakpoints when it resumes execution, until at
+_GDBN__ normally ignores breakpoints when it resumes execution, until at
least one instruction has been executed. If it did not do this, you
would be unable to proceed past a breakpoint without first disabling the
breakpoint. This rule applies whether or not the breakpoint already
Set a watchpoint for an expression.
@end table
-GDB allows you to set any number of breakpoints at the same place in the
+_GDBN__ allows you to set any number of breakpoints at the same place in the
program. There is nothing silly or meaningless about this. When the
breakpoints are conditional, this is even useful (@pxref{Conditions}).
@subsection Breakpoints and Exceptions
@cindex exception handlers
-Some languages, such as GNU C++, implement exception handling. GDB
+Some languages, such as GNU C++, implement exception handling. _GDBN__
can be used to examine what caused the program to raise an exception
and to list the exceptions the program is prepared to handle at a
given point in time.
You can use @samp{info catch} to list active exception handlers;
@pxref{Frame Info}.
-There are currently some limitations to exception handling in GDB.
+There are currently some limitations to exception handling in _GDBN__.
These will be corrected in a future release.
@itemize @bullet
@item
-If you call a function interactively, GDB will normally return
+If you call a function interactively, _GDBN__ will normally return
control to you when the function has finished executing. If the call
raises an exception, however, the call may bypass the mechanism that
returns control to the user and cause the program to simply continue
-running until it hits a breakpoint, catches a signal that GDB is
+running until it hits a breakpoint, catches a signal that _GDBN__ is
listening for, or exits.
@item
You cannot raise an exception interactively.
they are in the program. With the @samp{delete} command you can delete
individual breakpoints by specifying their breakpoint numbers.
-It is not necessary to delete a breakpoint to proceed past it. GDB
+It is not necessary to delete a breakpoint to proceed past it. _GDBN__
automatically ignores breakpoints on the first instruction to be executed
when you continue execution without changing the execution address.
Break conditions may have side effects, and may even call functions in your
program. These may sound like strange things to do, but their effects are
completely predictable unless there is another enabled breakpoint at the
-same address. (In that case, GDB might see the other breakpoint first and
+same address. (In that case, _GDBN__ might see the other breakpoint first and
stop the program without checking the condition of this one.) Note that
breakpoint commands are usually more convenient and flexible for the
purpose of performing side effects when a breakpoint is reached
@kindex ignore
Set the ignore count of breakpoint number @var{bnum} to @var{count}.
The next @var{count} times the breakpoint is reached, your program's
-execution will not stop; other than to decrement the ignore count, GDB
+execution will not stop; other than to decrement the ignore count, _GDBN__
takes no action.
To make the breakpoint stop the next time it is reached, specify
use the @samp{cont} command, or @samp{step}, or any other command to
resume execution. However, if you do this, any further commands in the
same breakpoint's command list are ignored. When the program stops
-again, GDB will act according to the cause of that stop.
+again, _GDBN__ will act according to the cause of that stop.
@kindex silent
If the first command specified is @samp{silent}, the usual message about
One deficiency in the operation of automatically continuing breakpoints
under Unix appears when your program uses raw mode for the terminal.
-GDB switches back to its own terminal modes (not raw) before executing
+_GDBN__ switches back to its own terminal modes (not raw) before executing
commands, and then must switch back to raw mode when your program is
continued. This causes any pending terminal input to be lost.
In the GNU system, this will be fixed by changing the behavior of
@c Q in pending mail to Gilmore. ---pesch@cygnus.com, 26mar91
Under some operating systems, breakpoints cannot be used in a program if
any other process is running that program. In this situation,
-attempting to run or continue a program with a breakpoint will cause GDB
+attempting to run or continue a program with a breakpoint will cause _GDBN__
to stop the other process.
When this happens, you have three ways to proceed:
Remove or disable the breakpoints, then continue.
@item
-Suspend GDB, and copy the file containing the program to a new name.
-Resume GDB and use the @samp{exec-file} command to specify that GDB
+Suspend _GDBN__, and copy the file containing the program to a new name.
+Resume _GDBN__ and use the @samp{exec-file} command to specify that _GDBN__
should run the program under that name. Then start the program again.
@item
stack frames are allocated in a region of memory called the @dfn{call
stack}.
-When your program stops, the GDB commands for examining the stack allow you
+When your program stops, the _GDBN__ commands for examining the stack allow you
to see all of this information.
-One of the stack frames is @dfn{selected} by GDB and many GDB commands
+One of the stack frames is @dfn{selected} by _GDBN__ and many _GDBN__ commands
refer implicitly to the selected frame. In particular, whenever you ask
-GDB for the value of a variable in the program, the value is found in the
-selected frame. There are special GDB commands to select whichever frame
+_GDBN__ for the value of a variable in the program, the value is found in the
+selected frame. There are special _GDBN__ commands to select whichever frame
you are interested in.
-When the program stops, GDB automatically selects the currently executing
+When the program stops, _GDBN__ automatically selects the currently executing
frame and describes it briefly as the @samp{frame} command does
(@pxref{Frame Info, Info}).
going on in that frame.
@cindex frame number
-GDB assigns numbers to all existing stack frames, starting with zero for
+_GDBN__ assigns numbers to all existing stack frames, starting with zero for
the innermost frame, one for the frame that called it, and so on upward.
These numbers do not really exist in your program; they are to give you a
-way of talking about stack frames in GDB commands.
+way of talking about stack frames in _GDBN__ commands.
@cindex selected frame
-Many GDB commands refer implicitly to one stack frame, called the
+Many _GDBN__ commands refer implicitly to one stack frame, called the
@dfn{selected} stack frame. You can select any frame using one set of
-GDB commands, and then other commands will operate on that frame. When
-your program stops, GDB automatically selects the innermost frame.
+_GDBN__ commands, and then other commands will operate on that frame. When
+your program stops, _GDBN__ automatically selects the innermost frame.
@cindex frameless execution
Some compilers allow functions to be compiled to run without a frame
-reserved for them on the stack. (For example, the GCC option
+reserved for them on the stack. (For example, the _GCC__ option
@samp{-fomit-frame-pointer} will generate functions without a frame.)
This is occasionally done with heavily used library functions to save
-the frame setup time. GDB has limited facilities for dealing with these
+the frame setup time. _GDBN__ has limited facilities for dealing with these
function invocations; if the innermost function invocation has no stack
-frame, GDB will give it a virtual stack frame of 0 and correctly allow
+frame, _GDBN__ will give it a virtual stack frame of 0 and correctly allow
tracing of the function call chain. Results are undefined if a function
invocation besides the innermost one is frameless.
@item frame @var{addr}
Select the frame at address @var{addr}. This is useful mainly if the
chaining of stack frames has been damaged by a bug, making it
-impossible for GDB to assign numbers properly to all frames. In
+impossible for _GDBN__ to assign numbers properly to all frames. In
addition, this can be useful when the program has multiple stacks and
switches between them.
These two commands are variants of @samp{up} and @samp{down},
respectively; they differ in that they do their work silently, without
causing display of the new frame. They are intended primarily for use
-in GDB command scripts, where the output might be unnecessary and
+in _GDBN__ command scripts, where the output might be unnecessary and
distracting.
@end table
@node Source, Data, Stack, Top
@chapter Examining Source Files
-GDB knows which source files your program was compiled from, and
-can print parts of their text. When your program stops, GDB
+_GDBN__ knows which source files your program was compiled from, and
+can print parts of their text. When your program stops, _GDBN__
spontaneously prints the line it stopped in. Likewise, when you
-select a stack frame (@pxref{Selection}), GDB prints the line
+select a stack frame (@pxref{Selection}), _GDBN__ prints the line
which execution in that frame has stopped in. You can also
print parts of source files by explicit command.
Executable programs sometimes do not record the directories of the source
files from which they were compiled, just the names. Even when they do,
the directories could be moved between the compilation and your debugging
-session. GDB remembers a list of directories to search for source files;
-this is called the @dfn{source path}. Each time GDB wants a source file,
+session. _GDBN__ remembers a list of directories to search for source files;
+this is called the @dfn{source path}. Each time _GDBN__ wants a source file,
it tries all the directories in the list, in the order they are present
in the list, until it finds a file with the desired name. Note that
the executable search path is @emph{not} used for this purpose. Neither is
path.
If it can't find a source file in the source path, and the object program
-records what directory it was compiled in, GDB tries that directory too.
+records what directory it was compiled in, _GDBN__ tries that directory too.
If the source path is empty, and there is no record of the compilation
-directory, GDB will, as a last resort, look in the current directory.
+directory, _GDBN__ will, as a last resort, look in the current directory.
-Whenever you reset or rearrange the source path, GDB will clear out
+Whenever you reset or rearrange the source path, _GDBN__ will clear out
any information it has cached about where source files are found, where
each line is in the file, etc.
@kindex directory
-When you start GDB, its source path is empty.
+When you start _GDBN__, its source path is empty.
To add other directories, use the @samp{directory} command.
@table @code
@end table
Because the @samp{directory} command, when used with arguments, adds to
-the front of the source path, it can affect files that GDB has already
+the front of the source path, it can affect files that _GDBN__ has already
found. If the source path contains directories that you do not want,
and these directories contain misleading files with names matching your
source files, the way to correct the situation is as follows:
@section Expressions
@cindex expressions
-Many different GDB commands accept an expression and compute its value.
+Many different _GDBN__ commands accept an expression and compute its value.
Any kind of constant, variable or operator defined by the programming
-language you are using is legal in an expression in GDB. This includes
+language you are using is legal in an expression in _GDBN__. This includes
conditional expressions, function calls, casts and string constants. It
unfortunately does not include symbols defined by preprocessor
@code{#define} commands, or C++ expressions involving @samp{::}, the
useful to cast a number into a pointer so as to examine a structure
at that address in memory.
-GDB supports three kinds of operator in addition to those of programming
+_GDBN__ supports three kinds of operator in addition to those of programming
languages:
@table @code
@cindex name resolution (C++)
Unfortunately, this use of @samp{::} conflicts with the very similar use
-of the same notation in C++; accordingly, GDB does not support use of
-the C++ name resolution operator in GDB expressions.
+of the same notation in C++; accordingly, _GDBN__ does not support use of
+the C++ name resolution operator in _GDBN__ expressions.
@node Arrays, Format options, Variables, Data
@section Artificial Arrays
@section Format options
@cindex format options
-GDB provides a few ways to control how arrays, structures, and symbols are
+_GDBN__ provides a few ways to control how arrays, structures, and symbols are
printed.
@table @code
@item set array-max @var{number-of-elements}
@kindex set array-max
-If GDB is printing a large array, it will stop printing after it has
+If _GDBN__ is printing a large array, it will stop printing after it has
printed the number of elements set by the @samp{set array-max} command.
This limit also applies to the display of strings.
@item show array-max
@kindex show array-max
-Display the number of elements of a large array that GDB will print
+Display the number of elements of a large array that _GDBN__ will print
before losing patience.
@item set arrayprint
@itemx set arrayprint on
@kindex set arrayprint
-GDB will pretty print arrays. This format is more convenient to read,
+_GDBN__ will pretty print arrays. This format is more convenient to read,
but uses more space. The default is off.
@item set arrayprint off.
@item set addressprint
@item set addressprint on
@kindex set addressprint
-GDB will print memory addresses in stack traces, structure values, pointer
+_GDBN__ will print memory addresses in stack traces, structure values, pointer
values, breakpoints, etc. The default is on.
@item set addressprint off
@item set prettyprint on
@kindex set prettyprint
-Cause GDB to print structures in an indented format with one member per
+Cause _GDBN__ to print structures in an indented format with one member per
line, like this:
@example
@end example
@item set prettyprint off
-Cause GDB to print structures in a compact format, like this:
+Cause _GDBN__ to print structures in a compact format, like this:
@smallexample
$1 = @{next = 0x0, flags = @{sweet = 1, sour = 1@}, meat \
@item show prettyprint
@kindex show prettyprint
-Show which format GDB will use to print structures.
+Show which format _GDBN__ will use to print structures.
@item set unionprint on
@kindex set unionprint
-Tell GDB to print unions which are contained in structures. This is the
+Tell _GDBN__ to print unions which are contained in structures. This is the
default setting.
@item set unionprint off
-Tell GDB not to print unions which are contained in structures.
+Tell _GDBN__ not to print unions which are contained in structures.
@item show unionprint
@kindex show unionprint
-Ask GDB whether or not it will print unions which are contained in
+Ask _GDBN__ whether or not it will print unions which are contained in
structures.
For example, given the declarations
@cindex formatted output
@cindex output formats
-GDB normally prints all values according to their data types. Sometimes
+_GDBN__ normally prints all values according to their data types. Sometimes
this is not what you want. For example, you might want to print a number
in hex, or a pointer in decimal. Or you might want to view data in memory
at a certain address as a character string or an instruction. These things
nearest preceding symbol. This format can be used to discover where (in
what function) an unknown address is located:
@example
-(gdb) p/a 0x54320
+(_GDBP__) p/a 0x54320
$3 = 0x54320 <_initialize_vx+396>
@end example
@noindent
Note that no space is required before the slash; this is because command
-names in GDB cannot contain a slash.
+names in _GDBN__ cannot contain a slash.
To reprint the last value in the value history with a different format,
you can use the @samp{print} command with just a format and no
as a holdover from specific predecessor machines of the 1970's that really
did use two-byte words. But more generally the term `word' has always
referred to the size of quantity that a machine normally operates on and
-stores in its registers. This is 32 bits for all the machines that GDB
+stores in its registers. This is 32 bits for all the machines that _GDBN__
runs on.
@item g
@kindex $__
The addresses and contents printed by the @samp{x} command are not put in
the value history because there is often too much of them and they would
-get in the way. Instead, GDB makes these values available for subsequent
+get in the way. Instead, _GDBN__ makes these values available for subsequent
use in expressions as values of the convenience variables @code{$_} and
@code{$__}.
If you find that you want to print the value of an expression frequently
(to see how it changes), you might want to add it to the @dfn{automatic
-display list} so that GDB will print its value each time the program stops.
+display list} so that _GDBN__ will print its value each time the program stops.
Each expression added to the list is given a number to identify it;
to remove an expression from the list, you specify that number.
The automatic display looks like this:
@section Value History
@cindex value history
-Values printed by the @samp{print} command are saved in GDB's @dfn{value
+Values printed by the @samp{print} command are saved in _GDBN__'s @dfn{value
history} so that you can refer to them in other expressions. Values are
kept until the symbol table is re-read or discarded (for example with
the @samp{file} or @samp{symbol-file} commands). When the symbol table
@section Convenience Variables
@cindex convenience variables
-GDB provides @dfn{convenience variables} that you can use within GDB to
+_GDBN__ provides @dfn{convenience variables} that you can use within _GDBN__ to
hold on to a value and refer to it later. These variables exist entirely
-within GDB; they are not part of your program, and setting a convenience
+within _GDBN__; they are not part of your program, and setting a convenience
variable has no effect on further execution of your program. That's why
you can use them freely.
@i{@dots{}repeat that command by typing @key{RET}.}
@end example
-Some convenience variables are created automatically by GDB and given
+Some convenience variables are created automatically by _GDBN__ and given
values likely to be useful.
@table @code
displays the processor status register as @code{$psr} but you can also
refer to it as @code{$ps}.
-GDB always considers the contents of an ordinary register as an integer
+_GDBN__ always considers the contents of an ordinary register as an integer
when the register is examined in this way. Some machines have special
registers which can hold nothing but floating point; these registers are
considered floating point. There is no way to refer to the contents of an
sees. For example, the registers of the 68881 floating point
coprocessor are always saved in ``extended'' (raw) format, but all C
programs expect to work with ``double'' (virtual) format. In such
-cases, GDB normally works with the virtual format only (the format that
+cases, _GDBN__ normally works with the virtual format only (the format that
makes sense for your program), but the @samp{info registers} command
prints the data in both formats.
The commands described in this section allow you to inquire about the
symbols (names of variables, functions and types) defined in your
-program. This information is found by GDB in the symbol table loaded by
+program. This information is found by _GDBN__ in the symbol table loaded by
the @samp{symbol-file} command; it is inherent in the text of your
program and does not change as the program executes.
Once you think you have found an error in the program, you might want to
find out for certain whether correcting the apparent error would lead to
correct results in the rest of the run. You can find the answer by
-experiment, using the GDB features for altering execution of the
+experiment, using the _GDBN__ features for altering execution of the
program.
For example, you can store new values into variables or memory
the @samp{set variable} command. This command is identical to @samp{set}
except for its lack of subcommands.
-GDB allows more implicit conversions in assignments than C does; you can
+_GDBN__ allows more implicit conversions in assignments than C does; you can
freely store an integer value into a pointer variable or vice versa, and
any structure can be converted to any other structure that is the same
length or shorter.
@node Sequences, Emacs, Altering, Top
@chapter Canned Sequences of Commands
-Aside from breakpoint commands (@pxref{Break Commands}),GDB provides two
+Aside from breakpoint commands (@pxref{Break Commands}),_GDBN__ provides two
ways to store sequences of commands for execution as a unit:
user-defined commands and command files.
@section User-Defined Commands
@cindex user-defined command
-A @dfn{user-defined command} is a sequence of GDB commands to which you
+A @dfn{user-defined command} is a sequence of _GDBN__ commands to which you
assign a new name as a command. This is done with the @samp{define}
command.
Define a command named @var{commandname}. If there is already a command
by that name, you are asked to confirm that you want to redefine it.
-The definition of the command is made up of other GDB command lines,
+The definition of the command is made up of other _GDBN__ command lines,
which are given following the @samp{define} command. The end of these
commands is marked by a line containing @samp{end}.
stops execution of the user-defined command.
Commands that would ask for confirmation if used interactively proceed
-without asking when used inside a user-defined command. Many GDB commands
+without asking when used inside a user-defined command. Many _GDBN__ commands
that normally print messages to say what they are doing omit the messages
when used in user-defined command.
@section Command Files
@cindex command files
-A command file for GDB is a file of lines that are GDB commands. Comments
+A command file for _GDBN__ is a file of lines that are _GDBN__ commands. Comments
(lines starting with @samp{#}) may also be included. An empty line in a
command file does nothing; it does not mean to repeat the last command, as
it would from the terminal.
@cindex init file
-@cindex @file{.gdbinit}
-When you start GDB, it first executes commands from its @dfn{init files}.
-These are files named @file{.gdbinit}. GDB reads the init file (if any)
+@cindex @file{._GDBP__init}
+When you start _GDBN__, it first executes commands from its @dfn{init files}.
+These are files named @file{._GDBP__init}. _GDBN__ reads the init file (if any)
in your home directory and then the init file (if any) in the current
working directory. (The init files are not executed if the @samp{-nx}
option is given.) You can also request the execution of a command file
of the command file.
Commands that would ask for confirmation if used interactively proceed
-without asking when used in a command file. Many GDB commands that
+without asking when used in a command file. Many _GDBN__ commands that
normally print messages to say what they are doing omit the messages
when used in a command file.
@end table
@node Emacs, Remote, Sequences, Top
-@chapter Using GDB under GNU Emacs
+@chapter Using _GDBN__ under GNU Emacs
@cindex emacs
A special interface allows you to use GNU Emacs to view (and
edit) the source files for the program you are debugging with
-GDB.
+_GDBN__.
To use this interface, use the command @kbd{M-x gdb} in Emacs. Give the
executable file you want to debug as an argument. This command starts
-GDB as a subprocess of Emacs, with input and output through a newly
+_GDBN__ as a subprocess of Emacs, with input and output through a newly
created Emacs buffer.
-Using GDB under Emacs is just like using GDB normally except for two
+Using _GDBN__ under Emacs is just like using _GDBN__ normally except for two
things:
@itemize @bullet
@item
All ``terminal'' input and output goes through the Emacs buffer. This
-applies both to GDB commands and their output, and to the input and
+applies both to _GDBN__ commands and their output, and to the input and
output done by the program you are debugging.
This is useful because it means that you can copy the text of previous
All the facilities of Emacs' Shell mode are available for this purpose.
@item
-GDB displays source code through Emacs. Each time GDB displays a
+_GDBN__ displays source code through Emacs. Each time _GDBN__ displays a
stack frame, Emacs automatically finds the source file for that frame
and puts an arrow (@samp{=>}) at the left margin of the current line.
Emacs uses a separate buffer for source display, and splits the window
-to show both your GDB session and the source.
+to show both your _GDBN__ session and the source.
-Explicit GDB @samp{list} or search commands still produce output as
+Explicit _GDBN__ @samp{list} or search commands still produce output as
usual, but you probably will have no reason to use them.
@end itemize
@emph{Warning:} If the directory where your program resides is not your
current directory, it can be easy to confuse Emacs about the location of
the source files, in which case the auxiliary display buffer will not
-appear to show your source. GDB can find programs by searching your
-environment's @samp{PATH} variable, so the GDB I/O session will proceed
-normally; but Emacs doesn't get enough information back from GDB to
+appear to show your source. _GDBN__ can find programs by searching your
+environment's @samp{PATH} variable, so the _GDBN__ I/O session will proceed
+normally; but Emacs doesn't get enough information back from _GDBN__ to
locate the source files in this situation. To avoid this problem,
-either start GDB mode from the directory where your program resides, or
+either start _GDBN__ mode from the directory where your program resides, or
specify a full path name when prompted for the @kbd{M-x gdb} argument.
-A similar confusion can result if you use the GDB @samp{file} command to
+A similar confusion can result if you use the _GDBN__ @samp{file} command to
switch to debugging a program in some other location, from an existing
-GDB I/O buffer in Emacs.
+_GDBN__ I/O buffer in Emacs.
@end quotation
By default, @kbd{M-x gdb} calls the program called ``@code{gdb}''. If
-you need to call GDB by a different name (for example, if you keep
+you need to call _GDBN__ by a different name (for example, if you keep
several configurations around, with different names) you can set the
Emacs variable @code{gdb-command-name}; for example,
@example
in your @samp{.emacs} file) will make Emacs call the program named
``@code{mygdb}'' instead.
-In the GDB I/O buffer, you can use these special Emacs commands in
+In the _GDBN__ I/O buffer, you can use these special Emacs commands in
addition to the standard Shell mode commands:
@table @kbd
@item C-h m
-Describe the features of Emacs' GDB Mode.
+Describe the features of Emacs' _GDBN__ Mode.
@item M-s
-Execute to another source line, like the GDB @samp{step} command; also
+Execute to another source line, like the _GDBN__ @samp{step} command; also
update the display window to show the current file and location.
@item M-n
Execute to next source line in this function, skipping all function
-calls, like the GDB @samp{next} command. Then update the display window
+calls, like the _GDBN__ @samp{next} command. Then update the display window
to show the current file and location.
@item M-i
-Execute one instruction, like the GDB @samp{stepi} command; update
+Execute one instruction, like the _GDBN__ @samp{stepi} command; update
display window accordingly.
@item M-x gdb-nexti
-Execute to next instruction, using the GDB @samp{nexti} command; update
+Execute to next instruction, using the _GDBN__ @samp{nexti} command; update
display window accordingly.
@item C-c C-f
-Execute until exit from the selected stack frame, like the GDB
+Execute until exit from the selected stack frame, like the _GDBN__
@samp{finish} command.
@item M-c
@comment C-c C-p in emacs 19
-Continue execution of the program, like the GDB @samp{cont} command.
+Continue execution of the program, like the _GDBN__ @samp{cont} command.
@item M-u
@comment C-c C-u in emacs 19
Go up the number of frames indicated by the numeric argument
(@pxref{Arguments, , Numeric Arguments, emacs, The GNU Emacs Manual}),
-like the GDB @samp{up} command.@refill
+like the _GDBN__ @samp{up} command.@refill
@item M-d
@comment C-c C-d in emacs 19
Go down the number of frames indicated by the numeric argument, like the
-GDB @samp{down} command.
+_GDBN__ @samp{down} command.
@item C-x &
Read the number where the cursor is positioned, and insert it at the end
-of the GDB I/O buffer. For example, if you wish to disassemble code
+of the _GDBN__ I/O buffer. For example, if you wish to disassemble code
around an address that was displayed earlier, type @kbd{disassemble};
then move the cursor to the address display, and pick up the
argument for @samp{disassemble} by typing @kbd{C-x &}.
@item M-x gdb-display-frame
Explicitly request display of the source code surrounding the current
-frame location, in another window. GDB does this display automatically;
+frame location, in another window. _GDBN__ does this display automatically;
but if, for example, you accidentally kill the buffer where it is
displayed, this command is a way of getting it back.
@end table
In any source file, the Emacs command @kbd{C-x SPC} (@code{gdb-break})
-tells GDB to set a breakpoint on the source line point is on.
+tells _GDBN__ to set a breakpoint on the source line point is on.
The source files displayed in Emacs are in ordinary Emacs buffers
which are visiting the source files in the usual way. You can edit
-the files with these buffers if you wish; but keep in mind that GDB
+the files with these buffers if you wish; but keep in mind that _GDBN__
communicates with Emacs in terms of line numbers. If you add or
-delete lines from the text, the line numbers that GDB knows will cease
+delete lines from the text, the line numbers that _GDBN__ knows will cease
to correspond properly to the code.
@comment The following dropped because Epoch is nonstandard. Reactivate
each value is printed in its own window.
@end ignore
-@node Remote, GDB Bugs, Emacs, Top
+@node Remote, _GDBN__ Bugs, Emacs, Top
@chapter Remote Debugging
@cindex remote debugging
If you are trying to debug a program running on a machine that can't run
-GDB in the usual way, it is often useful to use remote debugging. For
+_GDBN__ in the usual way, it is often useful to use remote debugging. For
example, you might be debugging an operating system kernel, or debugging
a small system which does not have a general purpose operating system
-powerful enough to run a full-featured debugger. Currently GDB supports
+powerful enough to run a full-featured debugger. Currently _GDBN__ supports
remote debugging over a serial connection, and (using Sun RPC) over a
TCP/IP connection.
The program to be debugged on the remote machine needs to contain a
-debugging device driver which talks to GDB over the serial line. The
-same version of GDB that is used ordinarily can be used for this.
-Several sample remote debugging drivers are distributed with GDB; see
-the @file{README} file in the GDB distribution for more information.
+debugging device driver which talks to _GDBN__ over the serial line. The
+same version of _GDBN__ that is used ordinarily can be used for this.
+Several sample remote debugging drivers are distributed with _GDBN__; see
+the @file{README} file in the _GDBN__ distribution for more information.
@menu
* Remote Commands:: Commands used to start and finish remote debugging.
@end menu
-For details of the communication protocol, see the comments in the GDB
+For details of the communication protocol, see the comments in the _GDBN__
source file @file{remote.c}.
@node Remote Commands, , Remote, Remote
@section Commands for Remote Debugging
-To start remote debugging, first run GDB and specify as an executable file
-the program that is running in the remote machine. This tells GDB how
+To start remote debugging, first run _GDBN__ and specify as an executable file
+the program that is running in the remote machine. This tells _GDBN__ how
to find the program's symbols and the contents of its pure text. Then
establish communication using the @samp{target remote} command with a device
name as an argument. For example:
command.
Other remote targets be available in your
-configuration of GDB; use @samp{info targets} to list them.
+configuration of _GDBN__; use @samp{info targets} to list them.
@table @code
@item reset
interesting action) when a break is detected.
@end table
-@node GDB Bugs, Installing GDB, Remote, Top
+@node _GDBN__ Bugs, Installing _GDBN__, Remote, Top
@comment node-name, next, previous, up
-@chapter Reporting Bugs in GDB
-@cindex Bugs in GDB
-@cindex Reporting Bugs in GDB
+@chapter Reporting Bugs in _GDBN__
+@cindex Bugs in _GDBN__
+@cindex Reporting Bugs in _GDBN__
-Your bug reports play an essential role in making GDB reliable.
+Your bug reports play an essential role in making _GDBN__ reliable.
Reporting a bug may help you by bringing a solution to your problem, or it
may not. But in any case the important function of a bug report is to help
-the entire community by making the next version of GDB work better. Bug
-reports are your contribution to the maintenance of GDB.
+the entire community by making the next version of _GDBN__ work better. Bug
+reports are your contribution to the maintenance of _GDBN__.
In order for a bug report to serve its purpose, you must include the
information that makes for fixing the bug.
* Bug Reporting:: How to Report Bugs
@end menu
-@node Bug Criteria, Bug Reporting, GDB Bugs, GDB Bugs
+@node Bug Criteria, Bug Reporting, _GDBN__ Bugs, _GDBN__ Bugs
@section Have You Found a Bug?
@cindex Bug Criteria
@cindex Fatal Signal
@cindex Core Dump
If the debugger gets a fatal signal, for any input whatever, that is a
-GDB bug. Reliable debuggers never crash.
+_GDBN__ bug. Reliable debuggers never crash.
@item
@cindex error on Valid Input
-If GDB produces an error message for valid input, that is a bug.
+If _GDBN__ produces an error message for valid input, that is a bug.
@item
@cindex Invalid Input
-If GDB does not produce an error message for invalid input,
+If _GDBN__ does not produce an error message for invalid input,
that is a bug. However, you should note that your idea of
``invalid input'' might be our idea of ``an extension'' or ``support
for traditional practice''.
@item
If you are an experienced user of debugging tools, your suggestions
-for improvement of GDB are welcome in any case.
+for improvement of _GDBN__ are welcome in any case.
@end itemize
-@node Bug Reporting, , Bug Criteria, GDB Bugs
+@node Bug Reporting, , Bug Criteria, _GDBN__ Bugs
@section How to Report Bugs
@cindex Bug Reports
@cindex Compiler Bugs, Reporting
@comment "info@cygnus.com"---the latter will reach all of Cygnus)
@comment is welcome.
A number of companies and individuals offer support for GNU products.
-If you obtained GDB from a support organization, we recommend you
+If you obtained _GDBN__ from a support organization, we recommend you
contact that organization first.
Among these organizations are Cygnus Support (Palo Alto CA, USA); C2V
there.
@comment END NEUTRAL+HELPFUL section
-In any event, we also recommend that you send bug reports for GDB to one
+In any event, we also recommend that you send bug reports for _GDBN__ to one
of these addresses:
@example
@end example
@strong{Do not send bug reports to @samp{info-gdb}, or to
-@samp{help-gdb}, or to any newsgroups.} Most users of GDB do not want to
+@samp{help-gdb}, or to any newsgroups.} Most users of _GDBN__ do not want to
receive bug reports. Those that do, have asked to be on @samp{bug-gdb}.
The mailing list @samp{bug-gdb} has a newsgroup which serves as a
@itemize @bullet
@item
-The version of GDB. GDB announces it on startup; you can also print it
+The version of _GDBN__. _GDBN__ announces it on startup; you can also print it
at any time using @samp{info version}.
Without this, we won't know whether there is any point in looking for
-the bug in the current version of GDB.
+the bug in the current version of _GDBN__.
@item
A complete input script, and all necessary source files, that will
reproduce the bug.
@item
-What compiler (and its version) was used to compile GDB---e.g.
-``GCC-1.37.1''.
+What compiler (and its version) was used to compile _GDBN__---e.g.
+``_GCC__-1.37.1''.
@item
-What compiler (and its version) was used to compile GDB.
+What compiler (and its version) was used to compile _GDBN__.
@item
The command arguments you gave the compiler to compile that example and
A description of what behavior you observe that you believe is
incorrect. For example, ``It gets a fatal signal.''
-Of course, if the bug is that GDB gets a fatal signal, then we
+Of course, if the bug is that _GDBN__ gets a fatal signal, then we
will certainly notice it. But if the bug is incorrect output, we might
not notice unless it is glaringly wrong.
Even if the problem you experience is a fatal signal, you should still
say so explicitly. Suppose something strange is going on, such as,
-your copy of GDB is out of synch, or you have encountered a
+your copy of _GDBN__ is out of synch, or you have encountered a
bug in the C library on your system. (This has happened!) Your copy
might crash and ours would not. If you @i{told} us to expect a crash,
then when ours fails to crash, we would know that the bug was not
would not be able to draw any conclusion from our observations.
@item
-If you wish to suggest changes to the GDB source, send us context
-diffs. If you even discuss something in the GDB source, refer to
+If you wish to suggest changes to the _GDBN__ source, send us context
+diffs. If you even discuss something in the _GDBN__ source, refer to
it by context, not by line number.
The line numbers in our development sources don't match those in your
a patch is all we need. We might see problems with your patch and decide
to fix the problem another way, or we might not understand it at all.
-Sometimes with a program as complicated as GDB it is very hard to
+Sometimes with a program as complicated as _GDBN__ it is very hard to
construct an example that will make the program follow a certain path
through the code. If you don't send us the example, we won't be able
to construct one, so we won't be able to verify that the bug is fixed.
@include readline/inc-history.texinfo
@end iftex
-@node Installing GDB, License, GDB Bugs, Top
-@appendix Installing GDB
-@cindex configuring GDB
+@node Installing _GDBN__, License, _GDBN__ Bugs, Top
+@appendix Installing _GDBN__
+@cindex configuring _GDBN__
@cindex installation
-The script @samp{config.gdb} automates the process of preparing GDB for
+The script @samp{config.gdb} automates the process of preparing _GDBN__ for
installation; you can then use @samp{make} to actually build it. For
example,
@end example
@noindent
-is all that's required to install GDB on a Sun 3 running SunOS 4.
+is all that's required to install _GDBN__ on a Sun 3 running SunOS 4.
@table @code
@kindex config.gdb
@item config.gdb @var{machine}
@itemx config.gdb -srcdir=@var{dir} @var{machine}
-This is the most usual way of configuring GDB; to debug programs running
-on the same machine as GDB itself. If you wish to build the GDB binaries
+This is the most usual way of configuring _GDBN__; to debug programs running
+on the same machine as _GDBN__ itself. If you wish to build the _GDBN__ binaries
in a completely different directory from the sources, specify a path to
the source directory using the @samp{-srcdir} option.
@item config.gdb -host
@cindex host environments
-Display a list of supported host environments for GDB.
+Display a list of supported host environments for _GDBN__.
@item config.gdb @var{host} @var{target}
@itemx config.gdb -srcdir=@var{dir} @var{host} @var{target}
@cindex cross-debugging
-GDB can also be used as a cross-debugger, running on a machine of one
+_GDBN__ can also be used as a cross-debugger, running on a machine of one
type while debugging a program running on a machine of another type.
You configure it this way by specifying first the @var{host}, then the
@var{target} environment on the @code{config.gdb} argument list; the
-@var{host} is where GDB runs, and the @var{target} is where your program
+@var{host} is where _GDBN__ runs, and the @var{target} is where your program
runs. @xref{Remote}. Again, you can use @samp{-srcdir} to specify a
-path to the GDB source.
+path to the _GDBN__ source.
@item config.gdb -target
@cindex target environments
-Display a list of supported target environments for GDB.
+Display a list of supported target environments for _GDBN__.
@end table
-@node License, Commands, Installing GDB, Top
+@node License,,,
@unnumbered GNU GENERAL PUBLIC LICENSE
@center Version 1, February 1989
projects / binutils-gdb.git / commitdiff