|Debugging with GDB|
A gdb 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
step accepts an argument which is the number of times to
step, as in ‘step 5’. You can also use the
with no arguments. Some commands do not allow any arguments.
gdb command names may always be truncated if that abbreviation is
unambiguous. Other possible command abbreviations are listed in the
documentation for individual commands. In some cases, even ambiguous
abbreviations are allowed; for example,
s is specially defined as
step even though there are other commands whose
names start with
s. You can test abbreviations by using them as
arguments to the
A blank line as input to gdb (typing just <RET>) means to
repeat the previous command. Certain commands (for example,
will not repeat this way; these are commands whose unintentional
repetition might cause trouble and which you are unlikely to want to
repeat. User-defined commands can disable this feature; see
x commands, when you repeat them with
<RET>, construct new arguments rather than repeating
exactly as typed. This permits easy scanning of source or memory.
gdb can also use <RET> in another way: to partition lengthy
output, in a way similar to the common utility
(see Screen Size). Since it is easy to press one
<RET> too many in this situation, gdb disables command
repetition after any command that generates this sort of display.
Any text from a # to the end of the line is a comment; it does nothing. This is useful mainly in command files (see Command Files).
The Ctrl-o binding is useful for repeating a complex sequence of commands. This command accepts the current line, like <RET>, and then fetches the next line relative to the current line from the history for editing.