Breakpoints
The driver is responsible for monitoring two types of breakpoints: data breakpoints and code breakpoints. Data breakpoints are breakpoints that stop the execution of the code that eXDI is debugging when certain data is accessed. Code breakpoints are breakpoints that stop the execution of the code eXDI is debugging when a particular point in the code is reached. There are three types of instantiation for code breakpoints:
- Software: breakpoints normally achieved by replacing the instruction to break with a trap instruction.
- Hardware: breakpoints normally achieved by an address-comparison mechanism that halts the operating system. Due to physical resource constraints, there are generally fewer hardware breakpoints than software breakpoints. Hardware breakpoints have the advantage of not requiring the code to be called when created. Therefore, they work well in situations where you don't have software modules sending notifications when loading, provided you do not have any address collision.
- Algorithm: the eXDI driver is responsible for finding the best resources on the probe to instantiate the breakpoints. Algorithm breakpoints should use software breakpoints whenever possible for code in RAM, since there are fewer hardware breakpoints available. Also, when the driver supports stepping, and stepping is emulated by breakpoints, let the user determine whether to step in ROM or set user breakpoints whenever possible. If stepping is provided by the driver and is emulated by breakpoints, where a trade-off between stepping in ROM and setting user hardware breakpoints is possible, let the user select the choice through the driver configuration panel.
See Also
Last updated on Friday, October 08, 2004
© 1992-2003 Microsoft Corporation. All rights reserved.