Debugging with GDB Manual (5900-1473; WDB 6.2; January 2011)

argument in the innermost frame, GDB stops the
next time it reaches the current location; this may
be useful inside loops.
GDB normally ignores breakpoints when it resumes
execution, until at least one instruction has been
executed. If it did not do this, you would be unable
to proceed past a breakpoint without first disabling
the breakpoint. This rule applies whether or not the
breakpoint already existed when your program
stopped.
break ... if cond Set a breakpoint with condition cond; evaluate the
expression cond each time the breakpoint is
reached, and stop only if the value is nonzero―that
is, if cond evaluates as true. '...' stands for one
of the possible arguments described above (or no
argument) specifying where to break. See “Break
conditions” (page 54), for more information on
breakpoint conditions.
tbreak args Set a breakpoint enabled only for one stop. args
are the same as for the break command, and the
breakpoint is set in the same way, but the
breakpoint is automatically deleted after the first
time your program stops there. See “Disabling
breakpoints” (page 53).
hbreak args Set a hardware-assisted breakpoint. args are the
same as for the break command and the
breakpoint is set in the same way, but the
breakpoint requires hardware support and some
target hardware may not have this support. The
main purpose of this is EPROM/ROM code
debugging, so you can set a breakpoint at an
instruction without changing the instruction. This
can be used with the new trap-generation provided
by SPARClite DSU and some x86-based targets.
These targets will generate traps when a program
accesses some data or instruction address that is
assigned to the debug registers. However, the
hardware breakpoint registers can take a limited
number of breakpoints. For example, on the DSU,
only two data breakpoints can be set at a time, and
GDB will reject this command if more than two are
used. Delete or disable unused hardware
48 Stopping and Continuing