Breakpoints in Simics are set on physical, linear, or virtual address for read, write, or execute accesses. Linear address breakpoints are usually only supported by x86 processors. Figure 5 shows how to carry out a memory access to support breakpoints.
Simics keeps an updated list of virtual breakpoints for a given virtual context in a context object. A processor object must make sure that all accesses are checked against the list and trigger a breakpoint when there is a hit.
The processor object may cache the list internally for efficiency.
A processor that does not optimize the breakpoint checking internally can request that the context checks and triggers breakpoints.
It does that by calling the trigger_breakpoint function in the breakpoint_trigger interface with the handle set to BREAKPOINT_HANDLE_ANY.
There are two ways that the list of virtual address breakpoints can change and the processor must then refresh or invalidate its breakpoint information cache:
Breakpoint changes can be listened for either using the Core_Breakpoint_Change hap, or by registering callbacks through the breakpoint_change interface.
The active context is changed through the set_context function in the context_handler interface.
The direct_memory_lookup interface will return information flagging if breakpoints or tracers are present on a returned lookup.
If breakpoints or tracers are flagged and overlap with the access type the direct memory user wants to perform, then the access should be performed using the memory_space interface.
When accessing memory through the memory_space interface, physical address breakpoints will be handled by the memory-space and do not need to be handled in the cosimulator.
Unlike for virtual breakpoints, the cosimulator does not need to listen for new or changed physical breakpoints.
Any change to a physical breakpoint on a requested page will result in the page being invalidated through the direct_memory_update interface.
The interfaces directly related to implementing breakpoint support are: