A breakpoint suspends execution of a program. There are many kinds of breakpoints - line breakpoints, watch points, exceptions, method entry and exit, etc.. The kinds of breakpoints supported by a debugger will depend on the debugger's underlying architecture and the aggregate functions that can be built with it. For example, hit counts and conditional breakpoints could be implemented with client side evaluations if they are not supported natively. The platform provides interfaces and abstract base classes to subclass when implementing breakpoints, persistence, a breakpoints view, actions for enabling/disabling, and retargettable actions for toggling common breakpoint types. A debugger provides concrete implementations of breakpoints and a toggler to create/delete breakpoints.
Breakpoints model objects are specializations of IBreakpoint
. The platform also defines interfaces for ILineBreakpoint
and IWatchpoint
which are common to many debuggers. Each breakpoint object has an associated marker (IMarker
) used to persist state and to display the breakpoint in editor rulers. Like all debug model elements, a breakpoint provides custom labels and images via an IDebugModelPresentation
. Breakpoints must subclass one of the abstract classes provided by the platform - Breakpoint
or LineBreakpoint
. Marker extensions have super types allowing for multiple inheritance. The debug platform defines base marker types for generic breakpoints and line breakpoints that should be used when defining new breakpoint marker types.
The debug platform provides the org.eclipse.debug.core.breakpoints
extension point for contributing breakpoints. Each breakpoint extension is paired with an org.eclipse.core.resource.markers
extension, used to define the marker associated with the breakpoint. A breakpoint extension refers to its associated marker extension (via its identifier). When the workspace shuts down markers are persisted and breakpoint objects are discarded. When the workspace starts up again, the debug platform (breakpoint manager) instantiates and initializes a breakpoint object for each persisted breakpoint marker.
The IBreakpointManager
manages all breakpoints in the workspace and provides notification to IBreakpointListener
's as breakpoints are added, changed, and removed. An IDebugTarget
implements IBreakpointListener
and is responsible for installing, updating, and uninstalling breakpoints as they are modified. Breakpoints often exist in the workspace before a debug target is created (and after a debug target is terminated). These are commonly known as deferred breakpoints (i.e. deferred until such time that they can be installed in a target). When a debug target is created, it is responsible for retrieving and installing all relevant existing (deferred) breakpoints.
How does a debug target install a breakpoint? It depends entirely on the underlying debug architecture. For example, the Eclipse Java debugger uses the standard JDWP (Java Debug Wire Protocol) to communicate with a virtual machine (VM) launched in debug mode. The protocol allows a client to specify the locations of line breakpoints via line numbers. However, a line breakpoint can only be installed once its class has been loaded in the VM. Thus, the Java debugger listens for class load events from the VM and when a class is loaded that has a corresponding breakpoints in the workspace, it makes requests to install breakpoints at specific line numbers. When execution encounters a breakpoint, the VM notifies the JDWP client with an associated event. When a breakpoint is deleted in the workspace, the JDWP client removes its breakpoint request from the VM.
The debug platform provides a set of actions to create and delete (toggle) common types of breakpoints. This promotes a common look and feel among debuggers and avoids polluting the workbench menus with similarly named actions.
The actions ask the active part (view or editor) or selection for its IToggleBreakpointsTarget
adapter. It then interacts with the adapter to determine action enablement and toggle breakpoints.
This exercise demonstrates creating, installing, and hitting breakpoints. From the Welcome Samples
Page (Help -> Welcome -> Samples) Import the Counter sample into your workspace. Hint: to quickly find the
locations in the code that need to be completed, search for the text
"Exercise 3", or look for it in
the Tasks
view. Note: Tasks in the plugin.xml file do now show
up
automatically in the task view, only the tasks in the java files will
be there. For this exercise you must:
CounterToggleBreakpointsTarget
. CounterDebugTarget
target is created, and when it received breakpoint add notification.CounterTarget
receives breakpoint remove notification. CounterThread#executeNextInstruction()
.