A breakpoint provides the ability to tell the application that at a particular address or event, control is to be turned over to some other authority (in this case, the monitor/debugger). When the application relinquishes control, all context is made available to the debugger so that the debugger can display local variables, dump a stack trace, and so forth. For this discussion, I will describe two distinct types of breakpoints:

• Hard breakpoints Established by the monitor so that when the breakpoint occurs, the monitor s CLI takes control. There is no way to return to the application code after this breakpoint occurs unless the application is restarted.

• Soft breakpoints Established by the monitor for runtime analysis (referred to before as an auto-return breakpoint). When the instruction at the breakpoint executes, control transfers to the monitor code (through the exception handler). After storing some information, the monitor returns control to the application in real time. Soft breakpoints come in several different types. Each type alters some state maintained by the monitor. This state information can be statistics that reflect execution behavior or control values used by the monitor itself (possibly to change the action taken by the soft breakpoint handler). For reasons I ll explain later, a soft breakpoint is harder to implement than a hard breakpoint.

The breakpoint is usually inserted into the application by replacing the instruction at the specified address with some other instruction that triggers an exception. ^[1] From this point on, I refer...