+
Step 1 - Launching
The first task in integrating a debugger in Eclipse is creating and
managing the debugger process. The Eclipse Platform provides an
@@ -270,7 +296,7 @@ extensive API for this purpose, which is nicely presented in the article.
This section (as this tutorial) concentrates on the DSF-specific tasks
of launching the PDA debugger.-
Launch Delegate
+Launch Delegate
At first glance, there's nothing unusual about the PDA debugger launch delegate. Just like the Debug Platform version it:-
@@ -299,7 +325,7 @@ extension interface, in order to create a custom launch object:
- Serve as the root element of the PDA View Model hierarchy @@ -513,7 +539,8 @@ these race conditions.
- Lines 86-95 declare the commuication sockets. They are +
- Lines 86-95 declare the communication sockets. They are marked as thread-safe though only used by dedicated threads after being created. @@ -745,10 +773,11 @@ thread. -
- To identify the command -control instnace - In debugger sessions that connect to multiple +control instance
- To help control
@@ -828,13 +857,13 @@ debugger command protocol state - The PDA debug protocol is
stateless, which means that any command acts independently of any
commands that came before it. For debuggers which do have
protocol state, e.g. GDB/MI, the command control needs to check the
-context of each command and set the protocol by preceeding the command
+context of each command and set the protocol by preceding the command
being processed with other commands.
- Line 126 cretes the dummy View Model context which represents a +
- Line 126 creates the dummy View Model context which represents a terminated PDA program.
- Line 135 implements the elements update method which is called in
the DSF session thread.
@@ -1432,9 +1465,9 @@ implementation:
-
-
- Line 153 iterates through the udptes. The +
- Line 153 iterates through the updates. The
IElementLabelProvider.update() method takes an array of updates as an
-argument to allow the implementation to process the udpates in bunches,
+argument to allow the implementation to process the updates in bunches,
improving performance.
- Line 157 calls a subroutine to handle the terminated program @@ -1538,13 +1571,13 @@ method to retrieve additional information about the state of the PDA program. The label update is completed only after request monitor of this method is called.
- Lines 207-210 perform error handling. -
- Lines 213-229 finally calcuate the label string for the +
- Lines 213-229 finally calculate the label string for the
program.
- On line 227, The result of the getExecutionData() call, accessed using DataRequestMonitor.getData(), is used to fill in the reason for the current state of the program. -
- Line 230 writes the label to the upate. This call assumes +
- Line 230 writes the label to the update. This call assumes
that there is no columns in Debug view, so it uses 0 as the column index.
@@ -1552,7 +1585,7 @@ that there is no columns in Debug view, so it uses Delta
Translating the Data Model events into IModelDelta objects that can be
-processed by the Flehible Hierarchy views, is the most complicated task
+processed by the Flexible Hierarchy views, is the most complicated task
performed by the View Model infrastructure. The model deltas
require that a path be formed by the IModelDelta objects which matches
the hierarchy elements found in the view, including such details as
@@ -1687,19 +1720,19 @@ context to be selected.
Note: In theory, each VM Node should only generate delta flags that only affect its own elements. In this way, the layout of the VM Nodes in a view could -be costomized as needed. In practice, testing and fine-tuning of +be customized as needed. In practice, testing and fine-tuning of the view requires adjustments in the flags returned by the various VM Nodes in a given view. -Step 4 - Run Control
+Step 4 - Run Control
Up to this point most of the work in creating the new PDA debugger has gone into infrastructure. Now it is time to start adding functionality to do some actual debugging. The work needed to get run control functionality implemented is all encapsulated in the PDARunControl service.
-State Tracking
+State Tracking
The primary function of the run control system is to track the current execution state of the program and to issue the corresponding events to @@ -1814,7 +1847,7 @@ logic an improve the efficiency of the IDE commands.
-Commands
+Commands
The command control commands all follow the same patter shown below by example of the resume() command:
@@ -1862,7 +1895,7 @@ state flag. - Lines 244-253 send the resume command to the PDA debugger.
- Lines 247-252 adds error handling in case the result command -fails. It resotres the service state. +fails. It restores the service state.
- Line 251 calls the super class's handleErrorOrCancel()
method. The super class relays the error status to the parent
request monitor and completes it.
@@ -1873,8 +1906,9 @@ request monitor and completes it.
- Tracking program running state
- - Lines 183-186 determine if the breakpoint is enabled. If it
is not, the insert command fails with an expected error.
- - Line 188 retrieves the breakpoint type attribute, shich is used +
- Line 188 retrieves the breakpoint type attribute, which is used to determine which breakpoint insert subroutine to call.
- Line 196 retrieves the PDAProgramDMContext
from the breakpoint target context. This context is the only
@@ -2134,7 +2170,7 @@ The PDABreakpoints.removeBreakpoint() command takes the
IBreakpointDMContext as an argument, but otherwise follows the same
general logic as the insertBreakpoint() implementation.
Updating a Breakpoint
-Updating a breakpoint involves motifying some of the attributes of an +Updating a breakpoint involves modifying some of the attributes of an existing breakpoint. Not all debuggers may support this functionality and for debuggers that do, not all types of breakpoints and not all attributes may be updated. The IBreakpoints interface @@ -2216,11 +2252,12 @@ this field.
The simple PDA debugger does not track detailed breakpoint data, such has hit counts, addresses etc. So this function simply returns an error.
-Breakpoints Mediator
+Breakpoints Mediator
With the APIs for managing IDE and Target-Side breakpoints clearly defined, there is a need for a component which will keep the two sets -of breakpoint objects synchronized. DSF provides a standard -BreakpointsMediator service to accomplish this task.
+of breakpoint objects synchronized. DSF provides a standard BreakpointsMediator service to +accomplish this task.@@ -2239,49 +2276,619 @@ breakpoints
+The BreakpointsMediator +service is not meant to be sub-classed by specific debugger +integrations, however the specific IDE Breakpoint objects as well as +Target-Side Breakpoint attributes differ from debugger to +debugger. +Therefore, the Breakpoints Mediator requires a helper object, which +implements IBreakpointAttributeTranslator which encapsulates the +debugger-specific functionality. The most important function of +the attribute translator is to translate IDE Breakpoint attributes into +Target-Side breakpoint attributes. The following listing shows +how the PDA debugger implements this function:
-
--
-
- Target Side Breakpoints -
- Mediator -
- Diagram showing Mediator's role
-
-
Step 6 - Stack
--
-
- Command Cache at work
-
-
Step 7 - Source Display
--
-
- Source lookup director
-
-
Step 8 - Variables
--
-
- Reading and writing variables
-
- - Formatted values -
- Expressions view
-
-
+org.eclipse.dd.examples.dsf.timers.TimersVMNode - + style="font-family: monospace; font-weight: bold;">org.eclipse.dd.examples.pda.service.PDABreakpointAttributeTranslator +- getBreakpointAttributes()
++ 65: public List<Map<String, Object>> getBreakpointAttributes(IBreakpoint bp, boolean bpManagerEnabled)
66: throws CoreException
67: {
68: Map<String, Object> attrs = new HashMap<String, Object>();
70: // Check that the marker exists and retrieve its attributes.
71: // Due to accepted race conditions, the breakpiont marker may become null
72: // while this method is being invoked. In this case throw an exception
73: // and let the caller handle it.
74: IMarker marker = bp.getMarker();
75: if (marker == null || !marker.exists()) {
76: throw new DebugException(new Status(IStatus.ERROR, PDAPlugin.PLUGIN_ID, DebugException.REQUEST_FAILED, "Breakpoint marker does not exist", null));
77: }
78: // Suppress cast warning: platform is still on Java 1.3
79: @SuppressWarnings("unchecked")
80: Map<String, Object> platformBpAttrs = marker.getAttributes();
82: // Copy breakpoint attributes.
83: if (bp instanceof PDAWatchpoint) {
84: attrs.put(PDABreakpoints.ATTR_BREAKPOINT_TYPE, PDABreakpoints.PDA_WATCHPOINT);
86: copyAttributes(platformBpAttrs, attrs, fgPDAWatchpointAttributes);
87: } else if (bp instanceof PDALineBreakpoint) {
88: attrs.put(PDABreakpoints.ATTR_BREAKPOINT_TYPE, PDABreakpoints.PDA_LINE_BREAKPOINT);
89: attrs.put(PDABreakpoints.ATTR_PROGRAM_PATH, marker.getResource().getFullPath().toString());
91: copyAttributes(platformBpAttrs, attrs, fgPDALineBreakpointAttributes);
92: }
94: // If the breakpoint manager is disabled, override the enabled attribute.
95: if (!bpManagerEnabled) {
96: attrs.put(IBreakpoint.ENABLED, false);
97: }
99: // The breakpoint mediator allows for multiple target-side breakpoints
100: // to be created for each IDE breakpoint. Although in case of PDA this
101: // feature is never used, we still have to return a list of attributes.
102: List<Map<String, Object>> retVal = new ArrayList<Map<String, Object>>(1);
103: retVal.add(attrs);
104: return retVal;
105: }
107: private void copyAttributes(Map<String, Object> srcMap, Map<String, Object> destMap, String[] attrs) {
108: for (String attr : attrs) {
109: if (srcMap.containsKey(attr)) {
110: destMap.put(attr, srcMap.get(attr));
111: }
112: }
113: }Step 6 - Stack
+Command Cache
+A new feature introduced in this service is the command cache. +The command cache is a surprisingly simple mechanism for caching +service data which otherwise would need to be retrieved repeatedly from +the debugger back end. The command cache performs two functions:
+-
+
- Map Command objects to corresponding Command Result objects. +
- While waiting for a Command to be processed, queue incoming +Commands for the same data and complete them when the first Command is +completed. +
+
++++ +
++ +org.eclipse.dd.examples.pda.service.PDAStack +- getFrames() ++ + +
++ +244: public void getFrames(IDMContext context, final DataRequestMonitor<IFrameDMContext[]> rm) {
+
245: // Can only create stack frames for an execution context as a parent,
246: // however the argument context is a generic context type, so it could
247: // be an execution context, a frame, a variable, etc. Search the
248: // hierarchy of the argument context to find the execution one.
249: final IExecutionDMContext execCtx = DMContexts.getAncestorOfType(context, IExecutionDMContext.class);
250: if (execCtx == null) {
251: PDAPlugin.failRequest(rm, IDsfService.INVALID_HANDLE, "Invalid context " + context);
252: return;
253: }
255: // Execute the stack command and create the corresponding frame contexts.
256: fCommandCache.execute(
257: new PDAStackCommand(fCommandControl.getProgramDMContext()),
258: new DataRequestMonitor<PDAStackCommandResult>(getExecutor(), rm) {
259: @Override
260: protected void handleOK() {
261: IFrameDMContext[] frameCtxs = new IFrameDMContext[getData().fFrames.length];
262: for (int i = 0; i < getData().fFrames.length; i++) {
263: frameCtxs[i] = new FrameDMContext(getSession().getId(), execCtx, i);
264: }
265: rm.setData(frameCtxs);
266: rm.done();
267: }
268: });
269: }-
+
- Lines 256-268 create a new PDAStackCommand, and execute it using
+the command cache.
+
+ - If the PDAStackCommand
+was previously executed, the PDAStackCommandResult
+object will be returned from the cached data.
+
+ - If the PDAStackCommand
+was just sent to the debugger, and the cache is waiting for the result,
+this request monitor will be put in a queue to wait for the
+result.
+
+ - If the cache does not contain an entry for the PDAStackCommand, it will create one
+and send it to the debugger.
+
+ - Lines 261-266 implement the handler which processes the PDAStackCommandResult. It
+creates an array of FrameDMContext objects and returns it to the client.
+
+
-
+
Frame Context
+The primary object type managed by the stack service a stack +frame. It is implemented by the FrameDMContext object listed +below:
+
++++ +
++ +org.eclipse.dd.examples.pda.service.PDAStack +- FrameDMContext ++ + +
++ +54: private static class FrameDMContext extends AbstractDMContext implements IFrameDMContext {
+
56: final private int fLevel;
58: FrameDMContext(String sessionId, IExecutionDMContext execDmc, int level) {
59: super(sessionId, new IDMContext[] { execDmc });
60: fLevel = level;
61: }
63: public int getLevel() { return fLevel; }
65: @Override
66: public boolean equals(Object other) {
67: return super.baseEquals(other) && ((FrameDMContext)other).fLevel == fLevel;
68: }
70: @Override
71: public int hashCode() {
72: return super.baseHashCode() ^ fLevel;
73: }
75: @Override
76: public String toString() {
77: return baseToString() + ".frame[" + fLevel + "]"; //$NON-NLS-1$ //$NON-NLS-2$
78: }
79: }-
+
- Line 56 declares the only field in the frame object, which is the
+frame level.
+
+
+
++++ +
++ +org.eclipse.dd.examples.pda.service.PDAStack +- FrameDMData ++ + +
++ +85: private static class FrameDMData implements IFrameDMData {
+
87: final private PDAFrame fFrame;
89: FrameDMData(PDAFrame frame) {
90: fFrame = frame;
91: }
93: public String getFile() {
94: return fFrame.fFilePath.lastSegment();
95: }
97: public String getFunction() {
98: return fFrame.fFunction;
99: }
101: public int getLine() {
102: return fFrame.fLine + 1;
103: }
105: public int getColumn() {
106: return 0;
107: }
109: public IAddress getAddress() {
110: return null;
111: }
112: }Step 7 - Source +Display
+Integrating source display is relatively simple task, even though the +Eclipse APIs for looking up and displaying source are rather +convoluted. Fortunately Eclipse Platform and DSF provide most of +the components needed to implement this functionality.
++ +
+The first step in integrating source lookup, is to create a source +lookup director and the source container. This is explained in +detail in the How +to write an Eclipse debugger article referenced earlier. +There is one difference in this process for a DSF-based debugger. +The source lookup director does not need to initialize a source lookup +participant list.+ +
++ + +Image 3: Components involved in Source +Display +
+
+The second step is to register a DSF source display adapter. +This has actually already +been accomplished in Step 3 - View +Model, when registering the View Model adapters.
+
+Step 8 - Variables
+At this point we almost have a fully functional PDA debugger. The +only thing that is left is to populate the Variables and Expressions +views.
+Displaying variable data in DSF requires use of two services:
+-
+
- IStack service -
+This service is used to get the list of local variables' names in a
+given stack frame.
+
+ - IExpressions service
+- This service is used to evaluate the variable names as expressions in
+order to retrieve full type and value information for the given
+variables.
+
+
Variable Contexts
+The stack service allows clients to retrieve two types of variables +through two methods
+-
+
- getLocals() - local variables +
- getArguments() - function arguments (not implemented by the PDA
+debugger)
+
+
+
++++ +
++ +org.eclipse.dd.examples.pda.service.PDAStack +- VariableDMContext ++ + +
++ +117: @Immutable
+
118: private static class VariableDMContext extends AbstractDMContext implements IVariableDMContext {
120: final private String fVariable;
122: VariableDMContext(String sessionId, IFrameDMContext frameCtx, String variable) {
123: super(sessionId, new IDMContext[] { frameCtx });
124: fVariable = variable;
125: }
127: String getVariable() { return fVariable; }
129: @Override
130: public boolean equals(Object other) {
131: return super.baseEquals(other) && ((VariableDMContext)other).fVariable.equals(fVariable);
132: }
134: @Override
135: public int hashCode() {
136: return super.baseHashCode() + fVariable.hashCode();
137: }
139: @Override
140: public String toString() {
141: return baseToString() + ".variable(" + fVariable + ")"; //$NON-NLS-1$ //$NON-NLS-2$
142: }
143: }-
+
- Line 127 declares the fVariable
+(name) field which along with the parent context uniquely identifies a
+PDA variable.
+
+
+
++++ +
++ +org.eclipse.dd.examples.pda.service.PDAStack +- getLocals() ++ + +
++ +271: public void getLocals(final IFrameDMContext frameCtx, final DataRequestMonitor<IVariableDMContext[]> rm) {
+
272: // Execute the stack command again.
273: fCommandCache.execute(
274: new PDAStackCommand(fCommandControl.getProgramDMContext()),
275: new DataRequestMonitor<PDAStackCommandResult>(getExecutor(), rm) {
276: @Override
277: protected void handleOK() {
278: // Find the correct PDAFrame
279: int frameId = getData().fFrames.length - frameCtx.getLevel() - 1;
280: if (frameId < 0) {
281: PDAPlugin.failRequest(rm, IDsfService.INVALID_HANDLE, "Invalid frame level " + frameCtx);
282: return;
283: }
284: PDAFrame pdaFrame = getData().fFrames[frameId];
286: // Create variable contexts for all variables in frame.
287: IVariableDMContext[] variableCtxs = new IVariableDMContext[pdaFrame.fVariables.length];
288: for (int i = 0; i < pdaFrame.fVariables.length; i++) {
289: variableCtxs[i] = new VariableDMContext(getSession().getId(), frameCtx, pdaFrame.fVariables[i]);
290: }
291: rm.setData(variableCtxs);
292: rm.done();
293: }
294: });
296: }-
+
- Lines 273-294 send the stack +command to the PDA debugger through the command cache. +
- Lines 279-284 verify the stack frame number and retrieve the +corresponding PDAFrame object +from the stack result. +
- Lines 287-290 create the variable Data Model contexts and return +then to the caller. +
+Expression Contexts
+The IExpressions interface +uses a somewhat unusual way of managing contexts. A client can +create an IExpressionDMContext +context instance for any expression and +parent context by calling the IExpressions.createExpressions() +method. However, when the returned expression context is +evaluated, if its expression is not valid or if it uses an invalid +parent context, it is guaranteed to fail. The +PDAExpressions.createExpression() implementation reflects this:
+
++++ +
++ +org.eclipse.dd.examples.pda.service.PDAExpressions +- createExpression() ++ + +
++ +213: public IExpressionDMContext createExpression(IDMContext ctx, String expression) {
+
214: // Create an expression based on the given context and string expression.
215: // The PDA debugger can only evaluate variables as expressions and only
216: // in context of a frame.
217: IFrameDMContext frameCtx = DMContexts.getAncestorOfType(ctx, IFrameDMContext.class);
218: if (frameCtx != null) {
219: return new ExpressionDMContext(getSession().getId(), frameCtx, expression);
220: } else {
221: // If a frame cannot be found in context, return an "invalid"
222: // expression context, because a null return value is not allowed.
223: // Evaluating an invalid expression context will always yield an
224: // error.
225: return new InvalidExpressionDMContext(getSession().getId(), ctx, expression);
226: }
227: }
+Expression Data
+The IExpressions interface allows for retrieving data in two stages:
+
+-
+
- Variable type and other data. +
- Variable value. +
+Formatted Value +Context
+The IExpressions service allows expression values to be retrieved in +different, client-selectable formats. For the PDA debugger, only +one formatting is available, which is reflected in the implementation +of +IFormattedValues.getAvailableFormats() +method. Also, the implementation of the IFormattedValues.getFormattedValueContext() +method is just a formality.
+
+
++++ +
++ +org.eclipse.dd.examples.pda.service.PDAExpressions +- getAvailableFormats() ++ + +
++ +262: public void getAvailableFormats(IFormattedDataDMContext dmc, DataRequestMonitor<String[]> rm) {
+
263: // PDA debugger doesn't support formatting the expression. Natural
264: // formatting is the only available option.
265: rm.setData(new String[] { NATURAL_FORMAT });
266: rm.done();
267: }
269: public FormattedValueDMContext getFormattedValueContext(IFormattedDataDMContext exprCtx, String formatId) {
270: // Creates a context that can be used to retrieve a formatted value.
271: return new FormattedValueDMContext(this, exprCtx, formatId);
272: }
+Only when the formatted vlaue context is evaluated, the var command is sent to the PDA +debugger:
+
++++ +
++ +org.eclipse.dd.examples.pda.service.PDAExpressions +- getFormattedExpressionValue() ++ + +
++ +274: public void getFormattedExpressionValue(FormattedValueDMContext formattedCtx,
+
275: final DataRequestMonitor<FormattedValueDMData> rm)
276: {
277: final ExpressionDMContext exprCtx = DMContexts.getAncestorOfType(formattedCtx, ExpressionDMContext.class);
278: if (exprCtx != null) {
279: final IFrameDMContext frameCtx = DMContexts.getAncestorOfType(exprCtx, IFrameDMContext.class);
280:
281: // First retrieve the stack depth, needed to properly calculate
282: // the frame index that is used by the PDAVarCommand.
283: fStack.getStackDepth(
284: frameCtx, 0,
285: new DataRequestMonitor<Integer>(getExecutor(), rm) {
286: @Override
287: protected void handleOK() {
288: // Calculate the frame index.
289: int frameId = getData() - frameCtx.getLevel() - 1;
290:
291: // Send the command to evaluate the variable.
292: fCommandCache.execute(
293: new PDAVarCommand(fCommandControl.getProgramDMContext(), frameId, exprCtx.getExpression()),
294: new DataRequestMonitor<PDACommandResult>(getExecutor(), rm) {
295: @Override
296: protected void handleOK() {
297: rm.setData(new FormattedValueDMData(getData().fResponseText));
298: rm.done();
299: }
300: });
301: }
302: });
303: } else {
304: PDAPlugin.failRequest(rm, INVALID_HANDLE, "Invalid expression context " + formattedCtx);
305: rm.done();
306: }
307: }-
+
- Line 277 extracts the expression context out of the formattedCtx argument. If the +expression context is not found, the evaluation is failed. +
- Line 283 calls the stack service to retrieve the stack +depth. This step is reqiured because the DPA debugger var command requires a stack frame +number which is counted from the bottom. Where as the stack frame +level returned in the IFrameDMCotnext.getLevel() +is counted at the top of the stack. +
- Line 289 calculates the frame number that can be used with the var command. +
- Lines 292-300 call the var command to evaluate the given
+expression and return the result to the client.
+
+
Additional Resources
+
+Debug Platform
+The platform team has evolved and improved the debug APIs over many +releases. Before starting a debugger integration using DSF, it +would be very helpful to familiarize yourself with materials in these +documents:
+-
+
- We
+Have Lift-off: The Launching Framework in Eclipse article
+
+ - How +to write an Eclipse debugger article. +
- Debug +Platform: The Basics EclipseCon tutorial. +
- Debug
+Platform: Custom Integration EclipseCon tutorial.
+
+
GDB
+The DSDP Device Debugging +project is developing a DSF-based debugger integration with GDB as +the main reference implementation of the DSF APIs. In comparison +with PDA, GDB is a much more complex and feature rich debugger +integration. The GDB debugger integration is also being +continually developed and improve features and performance.
+TCF
+The Target Communication Framework which is being developed as part of +the DSDP Target Management +project includes a reference debugger agent implementation. This +reference debugger agent is integrated with Eclipse using DSF. +The +TCF debugger is more limited in features than the GDB debugger, however +the TCF debugger API is considerably different than the GDB/MI protocol +and is an interesting example integration.
+
51: 51: public ILaunch getLaunch(ILaunchConfiguration configuration, String mode) throws CoreException {+ name="line59"> 59: }
52: // Need to configure the source locator before creating the launch
name="line55"> 55: // the source lookup adapter.
56: ISourceLocator locator = getSourceLocator(configuration);
58: return new PDALaunch(configuration, mode, locator);
59: }
PDALaunch
+PDALaunch
The PDALaunch object plays two main roles:-
Launch/Shutdown Sequence
+Launch/Shutdown +Sequence
The actual task of calling the asynchronous IDsfService's initialize() and -Step 2 - Connecting
+Step 2 - +Connecting
With the launch framework in place, the debugger back end is running and the DSF session and executor are started. The next step is to create the first service and to connect to the debugger. DSF @@ -604,7 +632,7 @@ target state change events.-
Synchronization
+Synchronization
Since there are several threads being used by the PDA Command Control protecting state data becomes very important.@@ -677,7 +705,7 @@ used only as a means of synchronization with the send job. flag. It needs to be thread safe to allow the command and event processing jobs to access it.
-
Command/Event Listeners
+Command/Event +Listeners
As mentioned before there are two types of listeners that can be -registered with the comands control: event -listners and command listeners. The most important +registered with the commands control: event +listeners and command listeners. The most important feature of these listeners, is that they are called by the command control synchronously. As a result of this, the command listeners can expect to see the state @@ -809,7 +838,7 @@ new command. send commands to the debugger. The separate runnable is used to allow the command listeners to modify the queue as well. -PDAProgramDMContext
+PDAProgramDMContext
Finally the command control also declares a Data Model context, which is a parent to all other contexts for a given PDA debugger session. Each command used with the command control has to @@ -820,7 +849,7 @@ instance returned by PDACommandControl.getProg However in other debuggers this context can have two other functions:PDA Commands
-To increase type safetly and make the code more readable the plain text +PDA Commands
+To increase type safely and make the code more readable the plain text PDA commands are abstracted using specific command objects. Below is an example of a command class:@@ -933,9 +962,12 @@ immutable helps guard the integrity of these caches. -
-
Step 3 - View Model
-Adapter Glue
+
+Step
+3 - View Model
+Adapter Glue
PDA View Model
+PDA View Model
The PDAVMAdapter creates the VM Providers on demand for each debugger view it supports:@@ -1203,7 +1236,7 @@ respectively. These providers are implemented in the -
Launch VM Provider
+Launch VM Provider
"Launch" actually refers to the internal name of the Debug view. The PDA debugger has a somewhat simpler presentation in Debug view than most debuggers because it does not support multiple threads so it has @@ -1288,7 +1321,7 @@ events. These events are used by the LaunchVMRootNode to update the state and content of the launch if it has been changed or terminated. -PDA Program VM Node
+PDA Program VM Node
Elements
@@ -1371,7 +1404,7 @@ already terminated. The super-class implementation only changes the execution thread to the DSF session and calls updateElementsInSessionThread(), which is not needed nor possible after the PDA program is terminated. -IExecutionDMData
-There is very little data that the run control servie interface returns +IExecutionDMData
+There is very little data that the run control service interface +returns for a given execution context. The intention behind this is to allow the service to remain very generic and thus applicable to any debugger. In specific debuggers, additional data about processes, @@ -1883,14 +1917,14 @@ extensions. IExpressionDMData is the only object which is retrieved asynchronously from the run control service, and it only contains the state change reason for the last debugger state change.-
Step 5 - Breakpoints
+Step 5 - Breakpoints
Managing breakpoints is one of the complicated tasks that need to be implemented by Eclipse debuggers. The source of this complexity is the fact that Eclipse breakpoints (IDE breakpoints) are managed independently of breakpoints that are installed in the debugger (target-side breakpoints). The Eclipse debugger integration has to keep these two sets of breakpoints synchronized.-
IDE Breakpoints
+IDE Breakpoints
Eclipse breakpoints are based on markers, which are special tags in the Eclispe resource system and are associated with files and folders. By using markers, breakpoints gain the benefit of the @@ -1924,8 +1958,10 @@ is described in fine detail the How to write an Eclipse debugger article.-
Target-Side Breakpoints
-DSF defines the IBreakpoints interface for a service which the fuctions +Target-Side +Breakpoints
+DSF defines the IBreakpoints interface for a service which the +functions of managing breakpoints installed on the target. These functions include:-
@@ -2054,7 +2090,7 @@ subroutine: