4.12 Breakpoints

Clients manipulate breakpoints in the instance by using the breakpoint_set() and breakpoint_clear() 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 invisible and undeletable breakpoints. 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 are specific to the target instance that contains them, not to the client that sets them. Breakpoint ids are specific to the instance.

The target instance implementation must ensure that after a breakpoint is hit, which stops 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.

This section contains the following subsections:
Non-ConfidentialPDF file icon PDF version101196_0100_00_en
Copyright © 2018 Arm Limited or its affiliates. All rights reserved.