[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Aside from breakpoint commands (see section Breakpoint command lists), GDB provides two ways to store sequences of commands for execution as a unit: user-defined commands and command files.
19.1 User-defined commands 19.2 User-defined command hooks 19.3 Command files 19.4 Commands for controlled output
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
A user-defined command is a sequence of GDB commands to
which you assign a new name as a command. This is done with the
define
command. User commands may accept up to 10 arguments
separated by whitespace. Arguments are accessed within the user command
via $arg0...$arg9. A trivial example:
define adder print $arg0 + $arg1 + $arg2 |
To execute the command use:
adder 1 2 3 |
This defines the command adder
, which prints the sum of
its three arguments. Note the arguments are text substitutions, so they may
reference variables, use complex expressions, or even perform inferior
functions calls.
define commandname
The definition of the command is made up of other GDB command lines,
which are given following the define
command. The end of these
commands is marked by a line containing end
.
if
else
, followed
by a series of commands that are only executed if the expression
was false. The end of the list is marked by a line containing end
.
while
if
: the command takes a single argument,
which is an expression to evaluate, and must be followed by the commands to
execute, one per line, terminated by an end
.
The commands are executed repeatedly as long as the expression
evaluates to true.
document commandname
help
. The command commandname must already be
defined. This command reads lines of documentation just as define
reads the lines of the command definition, ending with end
.
After the document
command is finished, help
on command
commandname displays the documentation you have written.
You may use the document
command again to change the
documentation of a command. Redefining the command with define
does not change the documentation.
help user-defined
show user
show user commandname
When user-defined commands are executed, the commands of the definition are not printed. An error in any command stops execution of the user-defined command.
If used interactively, commands that would ask for confirmation proceed without asking when used inside a user-defined command. Many GDB commands that normally print messages to say what they are doing omit the messages when used in a user-defined command.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
You may define hooks, which are a special kind of user-defined command. Whenever you run the command `foo', if the user-defined command `hook-foo' exists, it is executed (with no arguments) before that command.
A hook may also be defined which is run after the command you executed. Whenever you run the command `foo', if the user-defined command `hookpost-foo' exists, it is executed (with no arguments) after that command. Post-execution hooks may exist simultaneously with pre-execution hooks, for the same command.
It is valid for a hook to call the command which it hooks. If this occurs, the hook is not re-executed, thereby avoiding infinte recursion.
In addition, a pseudo-command, `stop' exists. Defining (`hook-stop') makes the associated commands execute every time execution stops in your program: before breakpoint commands are run, displays are printed, or the stack frame is printed.
For example, to ignore SIGALRM
signals while
single-stepping, but treat them normally during normal execution,
you could define:
define hook-stop handle SIGALRM nopass end define hook-run handle SIGALRM pass end define hook-continue handle SIGLARM pass end |
As a further example, to hook at the begining and end of the echo
command, and to add extra text to the beginning and end of the message,
you could define:
define hook-echo echo <<<--- end define hookpost-echo echo --->>>\n end (gdb) echo Hello World <<<---Hello World--->>> (gdb) |
You can define a hook for any single-word command in GDB, but
not for command aliases; you should define a hook for the basic command
name, e.g. backtrace
rather than bt
.
If an error occurs during the execution of your hook, execution of
GDB commands stops and GDB issues a prompt
(before the command that you actually typed had a chance to run).
If you try to define a hook which does not match any known command, you
get a warning from the define
command.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
A command file for GDB is a file of lines that are GDB commands. Comments (lines starting with #) 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.
When you start GDB, it automatically executes commands from its init files, normally called `.gdbinit'(6). During startup, GDB does the following:
The init file in your home directory can set options (such as `set complaints') that affect subsequent processing of command line options and operands. Init files are not executed if you use the `-nx' option (see section Choosing modes).
On some configurations of GDB, the init file is known by a different name (these are typically environments where a specialized form of GDB may need to coexist with other forms, hence a different name for the specialized version's init file). These are the environments with special init file names:
You can also request the execution of a command file with the
source
command:
source filename
The lines in a command file are executed sequentially. They are not printed as they are executed. An error in any command terminates execution 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 normally print messages to say what they are doing omit the messages when called from command files.
GDB also accepts command input from standard input. In this mode, normal output goes to standard output and error output goes to standard error. Errors in a command file supplied on standard input do not terminate execution of the command file -- execution continues with the next command.
gdb < cmds > log 2>&1 |
(The syntax above will vary depending on the shell used.) This example will execute commands from the file `cmds'. All output and errors would be directed to `log'.
[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
During the execution of a command file or a user-defined command, normal GDB output is suppressed; the only output that appears is what is explicitly printed by the commands in the definition. This section describes three commands useful for generating exactly the output you want.
echo text
A backslash at the end of text can be used, as in C, to continue the command onto subsequent lines. For example,
echo This is some text\n\ which is continued\n\ onto several lines.\n |
produces the same output as
echo This is some text\n echo which is continued\n echo onto several lines.\n |
output expression
output/fmt expression
print
. See section Output formats, for more information.
printf string, expressions...
printf (string, expressions...); |
For example, you can print two values in hex like this:
printf "foo, bar-foo = 0x%x, 0x%x\n", foo, bar-foo |
The only backslash-escape sequences that you can use in the format string are the simple ones that consist of backslash followed by a letter.
[ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Please send FSF & GNU inquiries & questions to [email protected]. There are also other ways to contact the FSF.
These pages are maintained by the GDB developers.
Copyright Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111, USA.
Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
This document was generated by GDB Administrator on March, 29 2002 using texi2html