Firing the Breakpoint Event
When the session debug manager (SDM) receives the load-complete event (as represented by the IDebugLoadCompleteEvent2 interface), it waits for the user to decide how to run the program being debugged (either run to a breakpoint or single-step into it). Once the user has decided, the SDM proceeds to bind all pending breakpoints by calling IDebugPendingBreakpoint2::Bind (as implemented in TextInterpreter by CPendingBreakpoint::Bind). The SDM then calls IDebugProgram2::Execute or IDebugProgram2::Step, based on the user’s choice. Finally, the SDM calls IDebugEngine2::ContinueFromSynchronousEvent to signal the debug engine that the SDM is done with the load-complete event.
The debug engine then does whatever is necessary to start execution of the program based on what the user selected. But just at the point when execution is about to begin, the debug engine sends to the SDM the entry-point event (as represented by the IDebugEntryPointEvent2 interface) telling the SDM that the program being debugged is ready to go. At this point, the SDM does whatever it needs to do to show that the program has started (for example, it tells the IDE to redraw the windows for the debug mode of Visual Studio) and then calls IDebugEngine2::ContinueFromSynchronousEvent once more to let the debug engine continue its job of monitoring the running program for breakpoint encounters.
In TextInterpreter, there is no real “running” of a program, so immediately after the entry point event is sent to the SDM, the last bound breakpoint is fired, simulating a breakpoint encounter; Visual Studio shows the breakpoint being encountered in the IDE.
Process
Firing a breakpoint event consists of the following steps: