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 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 affect
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 call 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 discards its symbol table, and reads it again. When it does this, GDB tries to retain your current breakpoints.
Go to the first, previous, next, last section, table of contents.