Debugging with GDB Manual The GNU Source-Level Debugger (769148-001, March 2014)

the command uses breakpoints, and hence is quicker than until without
an argument.
stepi, stepi arg,
si
Execute one machine instruction, then stop and return to the debugger.
It is often useful to do 'display/i $pc' when stepping by machine
instructions. This makes GDB automatically display the next instruction to
be executed, each time your program stops. See “Automatic display”
(page 62).
An argument is a repeat count, as in step.
nexti, nexti arg,
ni
Execute one machine instruction, but if it is a function call, proceed until
the function returns.
An argument is a repeat count, as in next.
Signals
A signal is an asynchronous event that can happen in a program. The operating system defines
the possible kinds of signals, and gives each kind a name and a number. For example, in Unix
SIGINT is the signal a program gets when you type an interrupt character (often C- c); SIGSEGV
is the signal a program gets from referencing a place in memory far away from all the areas in
use; SIGALRM occurs when the alarm clock timer goes off (which happens only if your program
has requested an alarm).
Some signals, including SIGALRM, are a normal part of the functioning of your program. Others,
such as SIGSEGV, indicate errors; these signals are fatal (they kill your program immediately) if
the program has not specified in advance some other way to handle the signal. SIGINT does not
indicate an error in your program, but it is normally fatal so it can carry out the purpose of the
interrupt: to kill the program.
GDB has the ability to detect any occurrence of a signal in your program. You can tell GDB in
advance what to do for each kind of signal.
Normally, GDB is set up to ignore non-erroneous signals like SIGALRM (so as not to interfere with
their role in the functioning of your program) but to stop your program immediately whenever an
error signal happens. You can change these settings with the handle command.
NOTE: Use caution if you disable all signals from certain processes. Disabling 'SIGTRAP' in
your program may cause your program to hang.
HP-UX uses 'SIGTRAP' to communicate with the debugger. If you disable all signals from certain
processes so that signals will be delivered to the right process, your program may hang when you
try to debug it. This behavior occurs because if you disable 'SIGTRAP', the debugger no longer
receives notification of events such as breakpoint hits and loading or unloading of shared libraries.
To prevent this problem:
Make certain you set this flag:
(gdb) set complain-if-sigtrap-disabled on
Also make certain the following warning was not emitted by the debugger before your program
hung:
Warning: Thread %d (in process %d) has disabled SIGTRAPs.
Debugging this thread is probably impossible.
If you do not want to see this message again, use:
"set complain-if-sigtrap-disabled 0"
info signals, info handle Print a table of all the kinds of signals and how GDB has
been told to handle each one. You can use this to see the
signal numbers of all the defined types of signals.
Signals 47