This section describes the advanced built-in predicates for creating and removing breakpoints.
add_breakpoint(:Spec, ?BID) development
Adds a breakpoint with a spec Spec, the breakpoint identifier assigned is unified with BID. Spec is one of the following:
standing for Tests
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
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
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, then a consistency error is
signaled. Module name expansion is performed for certain tests,
as described below.
Both the original and the transformed breakpoint specification is recorded
by the debugger. The original is returned in
current_breakpoint/5, while the transformed specification 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) development
Adds a conditional spypoint with a breakpoint specification formed by
pred(Pred) to the test part of Spec, for each
predicate Pred designated by the generalized predicate
current_breakpoint(:Spec, ?BID, ?Status, ?Kind, ?Type) development
There is a breakpoint with breakpoint specification Spec,
identifier BID, status Status, kind Kind, and type
Type. Status is one of
to enabled and disabled breakpoints. Kind is one of
generic, where MFunc is the module qualified
functor of the specific breakpoint. Type is the
current_breakpoint/5 enumerates all breakpoints on
The Spec as returned by
current_breakpoint/5 is exactly the
same as supplied at the creation of the breakpoint.
Removes, disables or enables the breakpoints with identifiers
specified by BIDs. BIDs can be a number, a list of
numbers or one of the atoms:
advice. The atoms specify all breakpoints, debugger
type breakpoints and advice type breakpoints, respectively.
Tests are satisfied in the current state of the execution.
Arbitrary tests can be used in this predicate, if it is called
from inside the debugger, i.e. from within a
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) development
Tests are satisfied in the state of the execution pointed to by FocusConditions (see Past States). An exception is raised if there is a non-backtraced test among Tests.
Note that the predicate arguments holding a breakpoint
specification (Spec or Tests above) are subject to module name
expansion. The first argument within simple tests
inherit the module name from the (module name expanded)
breakpoint specification/tests predicate argument, if there is
no explicit module qualification within the simple test. Within
flit(Old,New) command value settings, Old will
get the module name from the
by default, while New from the whole breakpoint specification
The following hook predicate can be used to customize the behavior of the interactive debugger.
This predicate is called for each debugger command that SICStus Prolog reads. The first argument is the abstract format of the debugger command DCommand, as returned by the query facility (see Query Processing). If it succeeds, then Actions is taken as the list of actions (see Action Conditions) to be done for the given debugger command. If it fails, then the debugger command is interpreted in the standard way.
Note that if a line typed in response to the debugger prompt cannot
be parsed as a debugger command, then
called with the term
Line is the code list typed in, with any leading whitespace
Warning is a warning message. This allows the user
to define new debugger commands, see Hooks Related to Breakpoints
for an example.