gdb.texinfo

早期freebsd实现

If the modification time of your symbol file has changed since the
last time _GDBN__ read its symbols, _GDBN__ will discard its symbol table and
re-read it.  When it does this, _GDBN__ tries to retain your current
breakpoints.

_if__(!_BARE__)
@node Arguments
@section Your Program's Arguments

@cindex arguments (to your program)
The arguments to your program can be specified by the arguments of the
@code{run} command.  They are passed to a shell, which expands wildcard
characters and performs redirection of I/O, and thence to your program.
_GDBN__ uses the shell indicated by your environment variable
@code{SHELL} if it exists; otherwise, _GDBN__ uses @code{/bin/sh}.

@code{run} with no arguments uses the same arguments used by the previous
@code{run}, or those set by the @code{set args} command.

@kindex set args
@table @code
@item set args
Specify the arguments to be used the next time your program is run.  If
@code{set args} has no arguments, @code{run} will execute your program
with no arguments.  Once you have run your program with arguments,
using @code{set args} before the next @code{run} is the only way to run
it again without arguments.

@item show args
@kindex show args
Show the arguments to give your program when it is started.
@end table

@node Environment
@section Your Program's Environment

@cindex environment (of your program)
The @dfn{environment} consists of a set of environment variables and
their values.  Environment variables conventionally record such things as
your user name, your home directory, your terminal type, and your search
path for programs to run.  Usually you set up environment variables with
the shell and they are inherited by all the other programs you run.  When
debugging, it can be useful to try running your program with a modified
environment without having to start _GDBN__ over again.

@table @code
@item path @var{directory}
@kindex path
Add @var{directory} to the front of the @code{PATH} environment variable
(the search path for executables), for both _GDBN__ and your program.
You may specify several directory names, separated by @samp{:} or
whitespace.  If @var{directory} is already in the path, it is moved to
the front, so it will be searched sooner.

You can use the string @samp{$cwd} to refer to whatever is the current
working directory at the time _GDBN__ searches the path.  If you use
@samp{.} instead, it refers to the directory where you executed the
@code{path} command.  _GDBN__ fills in the current path where needed in
the @var{directory} argument, before adding it to the search path.
@c 'path' is explicitly nonrepeatable, but RMS points out it is silly to
@c document that, since repeating it would be a no-op.

@item show paths
@kindex show paths
Display the list of search paths for executables (the @code{PATH}
environment variable).

@item show environment @r{[}@var{varname}@r{]}
@kindex show environment
Print the value of environment variable @var{varname} to be given to
your program when it starts.  If you do not supply @var{varname},
print the names and values of all environment variables to be given to
your program.  You can abbreviate @code{environment} as @code{env}.

@item set environment @var{varname} @r{[}=@r{]} @var{value}
@kindex set environment
Sets environment variable @var{varname} to @var{value}.  The value
changes for your program 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.
@c "any string" here does not include leading, trailing
@c blanks. Gnu asks: does anyone care?

For example, this command:

@example
set env USER = foo
@end example

@noindent
tells a Unix program, when subsequently run, that its user is named
@samp{foo}.  (The spaces around @samp{=} are used for clarity here; they
are not actually required.)

@item unset environment @var{varname}
@kindex unset environment
Remove variable @var{varname} from the environment to be passed to your
program.  This is different from @samp{set env @var{varname} =};
@code{unset environment} removes the variable from the environment,
rather than assigning it an empty value.
@end table

@node Working Directory
@section Your Program's Working Directory

@cindex working directory (of your program)
Each time you start your program with @code{run}, it inherits its
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 _GDBN__ with the @code{cd} command.

The _GDBN__ working directory also serves as a default for the commands
that specify files for _GDBN__ to operate on.  @xref{Files, ,Commands to
Specify Files}.

@table @code
@item cd @var{directory}
@kindex cd
Set _GDBN__'s working directory to @var{directory}.

@item pwd
@kindex pwd
Print _GDBN__'s working directory.
@end table

@node Input/Output
@section Your Program's Input and Output

@cindex redirection
@cindex i/o
@cindex terminal
By default, the program you run under _GDBN__ does input and output to
the same terminal that _GDBN__ uses.  _GDBN__ switches the terminal to
its own terminal modes to interact with you, but it records the terminal
modes your program was using and switches back to them when you continue
running your program.

@table @code
@item info terminal
@kindex info terminal
Displays _GDBN__'s recorded information about the terminal modes your
program is using.
@end table

You can redirect your program's input and/or output using shell
redirection with the @code{run} command.  For example,

_0__@example
run > outfile
_1__@end example

@noindent
starts your program, diverting its output to the file @file{outfile}.

@kindex tty
@cindex controlling terminal
Another way to specify where your program should do input and output is
with the @code{tty} command.  This command accepts a file name as
argument, and causes this file to be the default for future @code{run}
commands.  It also resets the controlling terminal for the child
process, for future @code{run} commands.  For example,

@example
tty /dev/ttyb
@end example

@noindent
directs that processes started with subsequent @code{run} commands
default to do input and output on the terminal @file{/dev/ttyb} and have
that as their controlling terminal.

An explicit redirection in @code{run} overrides the @code{tty} command's
effect on the input/output device, but not its effect on the controlling
terminal.

When you use the @code{tty} command or redirect input in the @code{run}
command, only the input @emph{for your program} is affected.  The input
for _GDBN__ still comes from your terminal.

@node Attach
@section Debugging an Already-Running Process
@kindex attach
@cindex attach

@table @code
@item attach @var{process-id}
This command
attaches to a running process---one that was started outside _GDBN__.
(@code{info files} will show your active targets.)  The command takes as
argument a process ID.  The usual way to find out the process-id of
a Unix process is with the @code{ps} utility, or with the @samp{jobs -l}
shell command.

@code{attach} will not repeat if you press @key{RET} a second time after
executing the command.
@end table

To use @code{attach}, you must be debugging in an environment which
supports processes.  You must also have permission to send the process a
signal, and it must have the same effective user ID as the _GDBN__
process.

When using @code{attach}, you should first use the @code{file} command
to specify the program running in the process and load its symbol table.
@xref{Files, ,Commands to Specify Files}.

The first thing _GDBN__ does after arranging to debug the specified
process is to stop it.  You can examine and modify an attached process
with all the _GDBN__ commands that are ordinarily available when you start
processes with @code{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 @code{continue} command after
attaching _GDBN__ to the process.

@table @code
@item detach
@kindex detach
When you have finished debugging the attached process, you can use the
@code{detach} command to release it from _GDBN__'s control.  Detaching
the process continues its execution.  After the @code{detach} command,
that process and _GDBN__ become completely independent once more, and you
are ready to @code{attach} another process or start one with @code{run}.
@code{detach} will not repeat if you press @key{RET} again after
executing the command.
@end table

If you exit _GDBN__ or use the @code{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 you need to confirm by using the @code{set confirm} command
(@pxref{Messages/Warnings, ,Optional Warnings and Messages}).

@node Kill Process
@c @group
@section Killing the Child Process

@table @code
@item kill
@kindex kill
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 of a
running process.  _GDBN__ ignores any core dump file while your program
is running.
@c @end group

On some operating systems, a program cannot be executed outside _GDBN__
while you have breakpoints set on it inside _GDBN__.  You can use the
@code{kill} command in this situation to permit running your program
outside the debugger.

The @code{kill} command is also useful if you wish to recompile and
relink your program, since on many systems it is impossible to modify an
executable file while it is running in a process.  In this case, when you
next type @code{run}, _GDBN__ will notice that the file has changed, and
will re-read the symbol table (while trying to preserve your current
breakpoint settings).

@node Process Information
@section Additional Process Information

@kindex /proc
@cindex process image
Some operating systems provide a facility called @samp{/proc} that can
be used to examine the image of a running process using file-system
subroutines.  If _GDBN__ is configured for an operating system with this
facility, the command @code{info proc} is available to report on several
kinds of information about the process running your program.

@table @code
@item info proc
@kindex info proc
Summarize available information about the process.

@item info proc mappings
@kindex info proc mappings
Report on the address ranges accessible in the program, with information
on whether your program may read, write, or execute each range.

@item info proc times
@kindex info proc times
Starting time, user CPU time, and system CPU time for your program and
its children.

@item info proc id
@kindex info proc id
Report on the process ID's related to your program: its own process id,
the id of its parent, the process group id, and the session id.

@item info proc status
@kindex info proc status
General information on the state of the process.  If the process is
stopped, this report includes the reason for stopping, and any signal
received.

@item info proc all
Show all the above information about the process.
@end table
_fi__(!_BARE__)

@node Stopping
@chapter Stopping and Continuing

The principal purpose of using a debugger is so that you can stop your
program before it terminates; or so that, if your program runs into
trouble, you can investigate and find out why.

Inside _GDBN__, your program may stop for any of several reasons, such
as a signal, a breakpoint, or reaching a new line after a _GDBN__
command such as @code{step}.  You may then examine and change
variables, set new breakpoints or remove old ones, and then continue
execution.  Usually, the messages shown by _GDBN__ provide ample
explanation of the status of your program---but you can also explicitly
request this information at any time.

@table @code
@item info program
@kindex info program
Display information about the status of your program: whether it is
running or not, what process it is, and why it stopped.
@end table

@menu
_if__(!_CONLY__)
* Breakpoints::                 Breakpoints, Watchpoints, and Exceptions
_fi__(!_CONLY__)
_if__(_CONLY__)
* Breakpoints::                 Breakpoints and Watchpoints
_fi__(_CONLY__)
* Continuing and Stepping::     Resuming Execution
_if__(_GENERIC__ || !_H8__)
* Signals::                     Signals
_fi__(_GENERIC__ || !_H8__)
@end menu

@node Breakpoints
_if__(!_CONLY__)
@section Breakpoints, Watchpoints, and Exceptions
_fi__(!_CONLY__)
_if__(_CONLY__)
@section Breakpoints and Watchpoints
_fi__(_CONLY__)

@cindex breakpoints
A @dfn{breakpoint} makes your program stop whenever a certain point in
the program is reached.  For each breakpoint, you can add various
conditions to control in finer detail whether your program will stop.
You can set breakpoints with the @code{break} command and its variants
(@pxref{Set Breaks, ,Setting Breakpoints}), to specify the place where
your program should stop by line number, function name or exact address
in the program.  
_if__(!_CONLY__)
In languages with exception handling (such as GNU C++), you can al