5.15 Breakpoints API

Clients manipulate breakpoints in an instance by using the breakpoint_set() and breakpoint_delete() functions.

Clients are encouraged to use the breakpoint_getList() function to display all breakpoints, instead of maintaining their own list of breakpoints. This ensures that breakpoints that are set by other clients are visible to the user, and avoids the program stopping on breakpoints that are invisible and undeletable by the user. The use of breakpoint_getAdditionalConditions() is exotic.


The term breakpoint is used here to refer to all types of breakpoints, including watchpoints and trigger points, which stop the entire simulation. When debugging an application that is running on an OS in a simulation, you usually would not use these breakpoints. This use case normally requires the simulation, and therefore the simulated OS, to continue running. Instead, you would use a debug server in the simulated world to stop the execution of the simulated application only. Iris does not support this type of application debugging.

Breakpoints and breakpoint ids are specific to the target instance that contains them, not to the client that sets them.

The target instance implementation must ensure that after a breakpoint is hit, stopping the simulation time, it is not immediately hit again when resuming the simulation time, for example by implementing a micro step.

Instances that support the breakpoint interface must also support the event interface. This allows clients to enable IRIS_BREAKPOINT_HIT events for an instance.

Debug accesses do not trigger breakpoints.

An IRIS_STATE_CHANGED event is generated when a breakpoint list changes.


$PVLIB_HOME/Iris/Examples/Client/Breakpoints/ contains an example client application that demonstrates how to use this API.
This section contains the following subsections:
Non-ConfidentialPDF file icon PDF version101196_0100_03_en
Copyright © 2018, 2019 Arm Limited or its affiliates. All rights reserved.