gdb: Conditions
5.1.6 Break Conditions
----------------------
The simplest sort of breakpoint breaks every time your program reaches a
specified place. You can also specify a "condition" for a breakpoint.
A condition is just a Boolean expression in your programming language
(
Expressions Expressions.). A breakpoint with a condition
evaluates the expression each time your program reaches it, and your
program stops only if the condition is _true_.
This is the converse of using assertions for program validation; in
that situation, you want to stop when the assertion is violated--that
is, when the condition is false. In C, if you want to test an assertion
expressed by the condition ASSERT, you should set the condition '!
ASSERT' on the appropriate breakpoint.
Conditions are also accepted for watchpoints; you may not need them,
since a watchpoint is inspecting the value of an expression anyhow--but
it might be simpler, say, to just set a watchpoint on a variable name,
and specify a condition that tests whether the new value is an
interesting one.
Break conditions can have side effects, and may even call functions
in your program. This can be useful, for example, to activate functions
that log program progress, or to use your own print functions to format
special data structures. The effects are completely predictable unless
there is another enabled breakpoint at the same address. (In that case,
GDB might see the other breakpoint first and stop your program without
checking the condition of this one.) Note that breakpoint commands are
usually more convenient and flexible than break conditions for the
purpose of performing side effects when a breakpoint is reached (
Breakpoint Command Lists Break Commands.).
Breakpoint conditions can also be evaluated on the target's side if
the target supports it. Instead of evaluating the conditions locally,
GDB encodes the expression into an agent expression (Agent
Expressions) suitable for execution on the target, independently of
GDB. Global variables become raw memory locations, locals become stack
accesses, and so forth.
In this case, GDB will only be notified of a breakpoint trigger when
its condition evaluates to true. This mechanism may provide faster
response times depending on the performance characteristics of the
target since it does not need to keep GDB informed about every
breakpoint trigger, even those with false conditions.
Break conditions can be specified when a breakpoint is set, by using
'if' in the arguments to the 'break' command. Setting
Breakpoints Set Breaks. They can also be changed at any time with the
'condition' command.
You can also use the 'if' keyword with the 'watch' command. The
'catch' command does not recognize the 'if' keyword; 'condition' is the
only way to impose a further condition on a catchpoint.
'condition BNUM EXPRESSION'
Specify EXPRESSION as the break condition for breakpoint,
watchpoint, or catchpoint number BNUM. After you set a condition,
breakpoint BNUM stops your program only if the value of EXPRESSION
is true (nonzero, in C). When you use 'condition', GDB checks
EXPRESSION immediately for syntactic correctness, and to determine
whether symbols in it have referents in the context of your
breakpoint. If EXPRESSION uses symbols not referenced in the
context of the breakpoint, GDB prints an error message:
No symbol "foo" in current context.
GDB does not actually evaluate EXPRESSION at the time the
'condition' command (or a command that sets a breakpoint with a
condition, like 'break if ...') is given, however.
Expressions Expressions.
'condition BNUM'
Remove the condition from breakpoint number BNUM. It becomes an
ordinary unconditional breakpoint.
A special case of a breakpoint condition is to stop only when the
breakpoint has been reached a certain number of times. This is so
useful that there is a special way to do it, using the "ignore count" of
the breakpoint. Every breakpoint has an ignore count, which is an
integer. Most of the time, the ignore count is zero, and therefore has
no effect. But if your program reaches a breakpoint whose ignore count
is positive, then instead of stopping, it just decrements the ignore
count by one and continues. As a result, if the ignore count value is
N, the breakpoint does not stop the next N times your program reaches
it.
'ignore BNUM COUNT'
Set the ignore count of breakpoint number BNUM to COUNT. The next
COUNT times the breakpoint is reached, your program's execution
does not stop; other than to decrement the ignore count, GDB takes
no action.
To make the breakpoint stop the next time it is reached, specify a
count of zero.
When you use 'continue' to resume execution of your program from a
breakpoint, you can specify an ignore count directly as an argument
to 'continue', rather than using 'ignore'. Continuing and
Stepping Continuing and Stepping.
If a breakpoint has a positive ignore count and a condition, the
condition is not checked. Once the ignore count reaches zero, GDB
resumes checking the condition.
You could achieve the effect of the ignore count with a condition
such as '$foo-- <= 0' using a debugger convenience variable that is
decremented each time. Convenience Variables Convenience
Vars.
Ignore counts apply to breakpoints, watchpoints, and catchpoints.
Info Catalog
gdb: Disabling
gdb: Breakpoints
gdb: Break Commands