Hello,
Option 1
-----------
The DSF API is quite different from what came before as it is entirely an asynchronous framework with a single executor thread.
There is an old
tutorial and examples (
here and
here) in the CDT repo that may help you in integrating. I also have a slightly less old repo that has some other
examples.
What you want to get the DsfSession from the GdbLaunch (implementation of ILaunch) with getSession() and then get its' executor (getExecutor()) and submit tasks (e.g. Runnable, Query or other types that can be submitted to the executor). Once in the executor thread, you can get services using the DsfServicesTracker (remember to dispose it) and then run methods on those services. You probably want the IRunControl service to do resume and suspend and IGDBControl for terminate.
Option 2
However, if you just need some basic functionality already handled by existing buttons (actions/commands) in Eclipse there may be a shortcut that will work for you. Instead of having to go through all the trouble of deep dives into DSF and its async programming model you may be able to just do the equivalent of pressing buttons in the UI by running handlers. These handlers are still async, but much simpler. This is not a way I have done it before, but you can do this:
// Resume selection in the Debug View
IAdaptable debugContext = DebugUITools.getDebugContext();
IResumeHandler resume = debugContext.getAdapter(IResumeHandler.class);
resume.execute(new DebugCommandRequest(new Object[] {debugContext}));
Where DebugCommandRequest is:
import org.eclipse.cdt.debug.internal.core.CRequest;
import org.eclipse.debug.core.commands.IDebugCommandRequest;
/** I have extended CRequest as a convenience for this email - it is up to you to decide to reimplement or use internals. */
public class DebugCommandRequest extends CRequest implements IDebugCommandRequest {
private Object[] elements;
public DebugCommandRequest(Object[] elements) {
this.elements = elements;
}
@Override
public Object[] getElements() {
return elements;
}
}
The advantage of this method is that it should work with CDI* too, so you can test it out on the old CDT and confirm it works with CDI. (In the CDI case the code above will simply adapt to something that eventually calls IDebugTarget or related classes.) That means less things changing at once for you and it means you can support both code bases at the same time while you transition.
The above code has only shown the execute use - you may want a canExecute call first depending on your use case.
Tying Options Together
-------------------------------
What you will find if you look under the hood is that Option 2 has an implementation of Option 1. Calling execute in option 2 to leads to
DsfResumeCommand.execute (the simple case is
executeSingle) which shows all the steps from Option 1.
Let us know how you get on with this. Others are in the same boat of upgrading to new frameworks and we can all benefit from what you learn.
HTH,
Jonah
* CDI - C Debug Interface is the name of the debug model that was part of CDT before DSF.
