Go to the previous, next section.
When you run a program under GDB, you must first generate debugging information when you compile it. You may start it with its arguments, if any, in an environment of your choice. You may redirect your program's input and output, debug an already running process, or kill a child process.
In order to debug a program effectively, you need to generate debugging information when you compile it. This debugging information is stored in the object file; it describes the data type of each variable or function and the correspondence between source line numbers and addresses in the executable code.
To request debugging information, specify the `-g' option when you run the compiler.
Many C compilers are unable to handle the `-g' and `-O' options together. Using those compilers, you cannot generate optimized executables containing debugging information.
GCC, the GNU C compiler, supports `-g' with or without `-O', making it possible to debug optimized code. We recommend that you always use `-g' whenever you compile a program. You may think your program is correct, but there is no sense in pushing your luck.
When you debug a program compiled with `-g -O', remember that the optimizer is rearranging your code; the debugger will show you what is really there. Do not be too surprised when the execution path does not exactly match your source file! An extreme example: if you define a variable, but never use it, GDB will never see that variable--because the compiler optimizes it out of existence.
Some things do not work as well with `-g -O' as with just `-g', particularly on machines with instruction scheduling. If in doubt, recompile with `-g' alone, and if this fixes the problem, please report it as a bug (including a test case!).
Older versions of the GNU C compiler permitted a variant option `-gg' for debugging information. GDB no longer supports this format; if your GNU C compiler has this option, do not use it.
run
r
run command to start your program under GDB. You must
first specify the program name
(except on VxWorks)
with an argument to GDB (see section Getting In and Out of GDB), or by using the file or exec-file
command (see section Commands to specify files).
If you are running your program in an execution environment that
supports processes, run creates an inferior process and makes
that process run your program. (In environments without processes,
run jumps to the start of your program.)
The execution of a program is affected by certain information it receives from its superior. GDB provides ways to specify this information, which you must do before starting your program. (You can change it after starting your program, but such changes will only affect your program the next time you start it.) This information may be divided into four categories:
run command. If a shell is available on your target, the shell
is used to pass the arguments, so that you may use normal conventions
(such as wildcard expansion or variable substitution) in describing
the arguments. In Unix systems, you can control which shell is used
with the SHELL environment variable. See section Your program's arguments.
set environment and unset
environment to change parts of the environment that will be given to
your program. See section Your program's environment.
cd command in GDB.
See section Your program's working directory.
run command line, or you can use the tty command to
set a different device for your program.
See section Your program's input and output.
Warning: While input and output redirection work, you cannot use pipes to pass the output of the program you are debugging to another program; if you attempt this, GDB is likely to wind up debugging the wrong program.
When you issue the run command, your program begins to execute
immediately. See section Stopping and Continuing, for discussion
of how to arrange for your program to stop. Once your program has
stopped, you may calls functions in your program, using the print
or call commands. See section Examining 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 it. When it does this, GDB tries to retain your current breakpoints.
The arguments to your program can be specified by the arguments of the
run command. They are passed to a shell, which expands wildcard
characters and performs redirection of I/O, and thence to your program.
Your SHELL environment variable (if it exists) specifies what
shell GDB if you do not define SHELL, GDB uses
/bin/sh.
run with no arguments uses the same arguments used by the previous
run, or those set by the set args command.
set args
set args has no arguments, run will execute your program
with no arguments. Once you have run your program with arguments,
using set args before the next run is the only way to run
it again without arguments.
show args
The 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 GDB over again.
path directory
PATH environment variable
(the search path for executables), for both GDB and your program.
You may specify several directory names, separated by `:' or
whitespace. If directory is already in the path, it is moved to
the front, so it will be searched sooner.
You can use the string `$cwd' to refer to whatever is the current
working directory at the time GDB searches the path. If you use
`.' instead, it refers to the directory where you executed the
path command. GDB fills in the current path where needed in
the directory argument, before adding it to the search path.
show paths
PATH
environment variable).
show environment [varname]
environment as env.
set environment varname [=] value
For example, this command:
set env USER = foo
tells a Unix program, when subsequently run, that its user is named `foo'. (The spaces around `=' are used for clarity here; they are not actually required.)
unset environment varname
unset environment removes the variable from the environment,
rather than assigning it an empty value.
Warning: GDB runs your program using the shell indicated
by your SHELL environment variable if it exists (or
/bin/sh if not). If your SHELL variable names a shell
that runs an initialization file--such as `.cshrc' for C-shell, or
`.bashrc' for BASH--any variables you set in that file will affect
your program. You may wish to move setting of environment variables to
files that are only run when you sign on, such as `.login' or
`.profile'.
Each time you start your program with run, it inherits its
working directory from the current working directory of GDB.
The GDB 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 cd command.
The GDB working directory also serves as a default for the commands that specify files for GDB to operate on. See section Commands to specify files.
By default, the program you run under GDB does input and output to the same terminal that GDB uses. GDB 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.
info terminal
You can redirect your program's input and/or output using shell
redirection with the run command. For example,
run > outfile
starts your program, diverting its output to the file `outfile'.
Another way to specify where your program should do input and output is
with the tty command. This command accepts a file name as
argument, and causes this file to be the default for future run
commands. It also resets the controlling terminal for the child
process, for future run commands. For example,
tty /dev/ttyb
directs that processes started with subsequent run commands
default to do input and output on the terminal `/dev/ttyb' and have
that as their controlling terminal.
An explicit redirection in run overrides the tty command's
effect on the input/output device, but not its effect on the controlling
terminal.
When you use the tty command or redirect input in the run
command, only the input for your program is affected. The input
for GDB still comes from your terminal.
attach process-id
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 ps utility,
or with the `jobs -l' shell command.
attach will not repeat if you press RET a second time after
executing the command.
To use 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 GDB
process.
When using attach, you should first use the file command
to specify the program running in the process and load its symbol table.
See section Commands to specify files.
The first thing GDB does after arranging to debug the specified
process is to stop it. You can examine and modify an attached process
with all the GDB commands that are ordinarily available when you start
processes with 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 continue command after
attaching GDB to the process.
detach
detach command to release it from GDB control. Detaching
the process continues its execution. After the detach command,
that process and GDB become completely independent once more, and you
are ready to attach another process or start one with run.
detach will not repeat if you press RET again after
executing the command.
If you exit GDB or use the 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 set confirm command
(see section Optional warnings and messages).
kill
This command is useful if you wish to debug a core dump instead of a running process. GDB ignores any core dump file while your program is running.
On some operating systems, a program cannot be executed outside GDB
while you have breakpoints set on it inside GDB. You can use the
kill command in this situation to permit running your program
outside the debugger.
The 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 run, GDB will notice that the file has changed, and
will re-read the symbol table (while trying to preserve your current
breakpoint settings).
Some operating systems provide a facility called `/proc' that can
be used to examine the image of a running process using file-system
subroutines. If GDB is configured for an operating system with this
facility, the command info proc is available to report on several
kinds of information about the process running your program.
info proc
info proc mappings
info proc times
info proc id
info proc status
info proc all
Go to the previous, next section.