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
Hello,

For clarification, neither option 1 or 2 have any UI dependencies. The only UI line is the very first line*, which is getting the selection from the Debug View - if you are not using it in the UI, you still need to have some handle to the debug target, so replace that line with something that is or can be adapted to what you need.

What is the type of object you are getting? Have you tried to adapt it to an IResumeHandler? 

Since it sounds like you may have an ILaunch type object (presumably/hopefully GdbLaunch?) then you need to get its "children" before you can do anything. e.g. 

// These two lines just used to get the current ILaunch
IAdaptable debugContext = DebugUITools.getDebugContext();
ILaunch launch = debugContext.getAdapter(ILaunch.class);

if (launch instanceof GdbLaunch) {
    GdbLaunch gdbLaunch = (GdbLaunch) launch;
    DsfSession session = gdbLaunch.getSession();
    DsfExecutor executor = session.getExecutor();
    executor.submit(() -> {
        // Use your plug-in Activator or similar for the bundle context
    BundleContext bundleContext = DsfPlugin.getBundleContext();
    DsfServicesTracker tracker = new DsfServicesTracker(bundleContext, session.getId());
    try {
        IGDBProcesses processes = tracker.getService(IGDBProcesses.class);
        IMIRunControl runcontrol = tracker.getService(IMIRunControl.class);
        ICommandControlService commandControl = tracker.getService(ICommandControlService.class);
        ICommandControlDMContext context = commandControl.getContext();

        processes.getProcessesBeingDebugged(context,
                new DataRequestMonitor<IDMContext[]>(executor, null) {
                    @Override
                    protected void handleSuccess() {
                        // data now contains all the processes being debugged.
                        // if you pass elements of data back to getProcessesBeingDebugged you can
                        // get the individual threads being debugged if you need that control.
                        IDMContext[] data = "">                        if (data[0] instanceof IExecutionDMContext) {
                            IExecutionDMContext execDmc = (IExecutionDMContext) data[0];
                            runcontrol.resume(execDmc, null);
                        }
                    }
                });
    } finally {
        tracker.dispose();
    }

});


* If I had written Option 1 out it would have had the same first line.

HTH,
Jonah

~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com


On Sat, 7 Dec 2019 at 09:34, Gidi Gal1 <GGal1@xxxxxxxxxx> wrote:
Hello Jonah,

Many thanks for your reply. I prefer option 1, I don't want to add dependencies to UI plugins in my plugin.
IRunControl.suspend and IRunControl.resume require IExecutionDMContext.
I understand that UI elements contain such objects. I'd rather not query UI elements, from the same reason I prefer option 1.
I read another discussion in cdt-dev that DSF events contain these objects as well. However, my scenario is that an external request leads to suspend\resume.
I found the following API relevant:
void org.eclipse.cdt.dsf.debug.service.IProcesses.attachDebuggerToProcess(IProcessDMContextprocCtx, DataRequestMonitor<IDMContext>rm)
In org.eclipse.cdt.dsf.gdb.internal.ui.osview.AttachProcessHandler there is a use of this API.
This API requires IProcessDMContext, which can be retrieved if we have the process id. However, when I look at the processes received from ILaunch, I don't have access to their ID's.

How can I find IExecutionDMContext without UI dependency or DSF event ?

Thanks,
Gidi





From:        Jonah Graham <jonah@xxxxxxxxxxxxxxxx>
To:        "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
Date:        12/04/2019 04:31 AM
Subject:        [EXTERNAL] Re: [cdt-dev] DSF and org.eclipse.debug.core.model.IDebugTarget
Sent by:        cdt-dev-bounces@xxxxxxxxxxx



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 tutorialand examples (hereand 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.

~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com


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

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.

Thanks.
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cdt-dev_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cdt-dev


_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cdt-dev

Back to the top