[cdt-dev] Handling multi core in DSF Services.

[Abeer Bagul <abeer4eclipse@xxxxxxxxx>]

Hi All,

This is a description of how we are handling multi core debugging using DSF in our IDE. 

Our IDE uses gdb to debug one core at a time. So for multi core debug sessions, we start multiple gdbs, each gdb handling one core. All these gdbs are a part of a single "Multi core" launch.

In DSF, each aspect of gdb is modeled using services, and each service interface defines various methods to allow operations on that aspect of gdb.
E.g., breakpoints are handled by MIBreakpoints and its methods such as addBreakpoint, removeBreakpoint, enableBreakpoint etc.

Each method takes a context object which represents the debug context for that operation. The root object of the context hierarchy is GDBControlDMContext, which represents one gdb. In the Debug view, the class GDBContainerDMC is the new equivalent of DebugTarget.

Since we have multiple service objects, one for each core, the main challenge was to intercept calls to a service from the UI and redirect that call to the core specific service, based on the given context object. To achieve this, we created one "MultiCoreService" class for each service type, and registered these service objects under their respective service interfaces. Each MultiCoreService object internally holds references to child service objects, one child service per gdb - core combination. 

The multicore service object manages the lifecycle of its internal child service objects. In this way, each launch has a single DSFSession object, and no patches to the UI / Core code are necessary. Only changes are that we cannot subclass GdbLaunch, and have to rewrite the ServicesLaunchSequence and FinalLaunchSequence to create the multicore service objects for each service interface, rather than the default gdb service objects.

Example of client interaction with multicore service object:
The ContainerVMNode queries for an object implementing IProcesses so that it can update the launch with child debug targets. In our case, it gets the multicore processes service. This service has a method getProcessesBeingDebugged(...) which has been overridden. This method ignores the incoming context object (ICommandControlDMContext) and instead, it queries all of its child services for containerDMCs. Thus, instead of returning a single containerDMC, this method now returns N containerDMCs for N gdb - core combinations.

Another example:
The multicore service object registered under MIRegisters service recieves a call to method getRegisterGroups(...). Here, the multicore object checks the passed context, and gets the corespecific service for that context from the service tracker. The call is then delegated to this child service object.

Getting core specific services from the service tracker has been implemented using OSGI filters, by embedding the corename into the child service's properties and using the corename in the filter when querying for a child service.

In this way, we were able to avoid patches to DSF - GDB and still support multiple backends in a single launch. This approach is not foolproof, since we are learning the framework as we go along. If anyone wants more specifics, please let me know.

Any feedback on pros and cons of this would be greatly appreciated :).

Thanks
Abeer Bagul