Events

The debugger engine provides facilities for monitoring and responding to events in the target. When an event occurs, the engine suspends the target (often only briefly), it then notifies all of the clients of the event, who in turn instruct the engine on how execution should proceed in the target.

To notify a client of an event, the engine calls the event callback object that is registered with the client. The engine provides each event callback with details of the event, and the event callback instructs the engine on how execution should proceed in the target. When different event callbacks provide conflicting instructions, the engine acts on the instruction with the highest precedence (see DEBUG_STATUS_XXX), which typically means choosing the instruction that involves the least execution of the target.

Note   While the event callback is handling the event, the target is suspended and the debugging session is accessible; however, because the engine was waiting for an event--either explicitly during a WaitForEvent call or implicitly by executing a command such as g (Go) or p (Step)--the event callback cannot call WaitForEvent, and if it attempts to execute any commands that would cause the debugger to execute, for example g (Go) or p (Step), the engine will interpret these commands as an instruction on how to proceed.

Event Filters

The debugger engine also provides event filters, which are a simpler alternative for basic event monitoring. The event filters provide a few simple rules that specify whether an event should be printed to the debugger's output stream or break into the debugger. They can also be used to execute debugger commands when an event occurs.

Additional Information

For details about monitoring events, see Monitoring Events.