Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] DSF and org.eclipse.debug.core.model.IDebugTarget


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;

    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.


* CDI - C Debug Interface is the name of the debug model that was part of CDT before DSF.

Jonah Graham
Kichwa Coders

On Tue, 3 Dec 2019 at 11:26, Gidi Gal1 <GGal1@xxxxxxxxxx> wrote:

I have code which integrated with the old debug API before DSF was added to Eclipse.
It uses 3 methods from org.eclipse.debug.core.model.IDebugTarget:
        - resume
        - terminate
        - suspend

It retrieves the IDebugTarget instance using org.eclipse.debug.core.ILaunch.getDebugTarget().
Now, when the old debug does not exist , I see that this call returns null.

Is this API still supported in DSF ?
If yes, please explain how to receive this instance in DSF.
If no, please explain how can I achieve the same behavior, using DSF API.

cdt-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Back to the top