eXDI Run-State Control (Windows Embedded CE 6.0)
1/5/2010
eXDI provides interfaces that allow you to have full run-state control. You can:
- Command the target device to reset, run, or halt
- Perform single-step
- Insert and manage code and data breakpoints
- Notify clients of halt reasons, and obtain client permission before resuming execution
- Change exception-handling actions
Target device control
You can command the target device to run, halt, or reset with the following methods:
- IeXdi2Exec::Run commands the target device to run. You can use this method to pass an exception on to the OS, or to designate an exception as Go Unhandled.
- IeXdi2Exec::Halt commands the target device to halt
- IeXdi2Exec::Reboot conducts and external reset of the target device.
Single Step
If a single-step primitive exists in the underlying hardware, you can use IeXdi2Exec::SingleStep to have the debugging target execute a single instruction and then halt. If no single-step primitive exists, you can have eXDI emulate single-step functionality by implementing single step as one of the eXDI helpers.
For more information about eXDI helpers, see Using the eXDI2 Helpers.
Breakpoints
eXDI provides interfaces that allow you to manage user code and data breakpoints, including hardware-based and software-based breakpoints.
IeXdi2Exec::AddCodeBps adds new code breakpoints. To enumerate user code breakpoints, you can use the IeXdi2EnumCodeBP interface. IeXdi2CodeBP provides methods to access a particular code breakpoint object.
IeXdi2Exec::AddDataBps adds new data breakpoints. To enumerate user data breakpoints, you can use the IeXdi2EnumDataBP interface. IeXdi2DataBP provides methods to access a particular data breakpoint object.
Halt notifications
eXDI notifies clients when execution is halted, through IeXdi2ClientNotifyRunChg::NotifyRunStateChange. The notification includes details about the halt reason, such as an exception, an asynchronous break, a breakpoint or single step, and so on.
Using the exception-filtering helper component, you can filter exceptions at the eXDI service level or below. In addition, you can use IeXdi2Exec::ChangeExceptionAction to change the action taken when an exception occurs. Note that this functionality is not controlled by the exception dialog.
For more information about using the exception-filtering component, see Using the eXDI2 Helpers.
Because a debugging client may be in the process of gathering or modifying information on the target, an eXDI service should obtain permission from the client before resuming execution with IeXdi2ClientAuthorizeContinuation::AuthorizeTargetRestart.