This section describes the advanced built-in predicates for creating and removing breakpoints.
add_breakpoint(
:Spec,
?BID)
development-
Actions-[]
-
Actions[]-
Actions
Here, both Tests and Actions are either a simple
Condition, see Breakpoint Conditions, or a composite
Condition. Conditions can be composed by forming lists, or by
using the ‘,’, ‘;’, ‘->’, and ‘\+’ operators,
with the usual meaning of conjunction, disjunction,
if-then-else, and negation, respectively. A list of conditions is
equivalent to a conjunction of the same conditions
([
A|
B]
is treated as (
A,
B)
).
The add_breakpoint/2
predicate performs some
transformations and checks before adding the breakpoint. All
condition macros invoked are expanded into their bodies, and this
process is repeated for the newly introduced bodies. The goal
and
pred
conditions are then extracted from the outermost
conjunctions of the test part and moved to the beginning of
the conjunction. If these are inconsistent, a consistency error is
signalled. Module name expansion is performed for certain tests,
as described below.
Both the original and the transformed breakpoint spec is recorded
by the debugger. The original is returned in
current_breakpoint/5
, while the transformed spec is used in
determining the applicability of breakpoints.
There can only be a single plain spypoint for each predicate. If a plain spypoint is added, and there is already a plain spypoint for the given predicate, then:
spy(
:PredSpec,
:Spec)
developmentpred(
Pred)
to the test part of Spec, for each
predicate Pred designated by the generalized predicate
spec PredSpec.
current_breakpoint(
:Spec,
?BID,
?Status,
?Kind,
?Type)
developmenton
or off
, referring
to enabled and disabled breakpoints. Kind is one of
plain(
MFunc)
, conditional(
MFunc)
or
generic
, where MFunc is the module qualified
functor of the specific breakpoint. Type is the
breakpoint type: debugger
or advice
.
current_breakpoint/5
enumerates all breakpoints on
backtracking.
The Spec as returned by current_breakpoint/5
is exactly the
same as supplied at the creation of the breakpoint,
remove_breakpoints(
+BIDs)
developmentdisable_breakpoints(
+BIDs)
developmentenable_breakpoints(
+BIDs)
developmentall
, debugger
,
advice
. The atoms specify all breakpoints, debugger
type breakpoints and advice type breakpoints, respectively.
execution_state(
:Tests)
developmenttrue
condition. Otherwise only those tests can be used, which query the data
stored in the backtrace. An exception is raised if the latter
condition is violated, i.e. a non-backtraced test
(see Breakpoint Conditions) occurs in a call of
execution_state/1
from outside the debugger.
execution_state(
+FocusConditions,
:Tests)
developmentNote that the predicate arguments holding a breakpoint
spec (Spec or Tests above) are subject to module name
expansion. The first argument within simple tests
goal(_)
, pred(_)
, parent_pred(_)
,
parent_pred(_,_)
, ancestor(_,_)
, and true(_)
will
inherit the module name from the (module name expanded)
breakpoint spec/tests predicate argument, if there is
no explicit module qualification within the simple test. Within
the proceed(
Old,
New)
and
flit(
Old,
New)
command value settings, Old will
get the module name from the goal
or pred
condition
by default, while New from the whole breakpoint spec
argument.
The following hook predicate can be used to customize the behavior of the interactive debugger.
debugger_command_hook(
+DCommand,
?Actions)
hook,developmentuser:debugger_command_hook(
+DCommand,
?Actions)
Note that if a line typed in response to the debugger prompt cannot
be parsed as a debugger command, debugger_command_hook/2
is
called with the term unknown(Line,Warning)
. Here,
Line
is the code-list typed in, with any leading whitespace
removed, and Warning
is a warning message. This allows the user
to define new debugger commands, see Hooks Related to Breakpoints
for an example.