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

[Marc Khouzam <marc.khouzam@xxxxxxxxxxxx>]

Hi Aberr,

Thanks for the very clearly writting info.
I am very happy to hear you were able to re-use DSF-GDB
and extend it in an impressive way.  Nice work.

I have one question below.

> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx 
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Abeer Bagul
> Sent: Monday, April 11, 2011 7:36 AM
> To: CDT General developers list.
> Subject: [cdt-dev] Handling multi core in DSF Services.
> 
> 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. 

So each DSF service, such as IBreakpoints, has one instance
for every gdb-core combination, which is the un-modified
DSF-GDB version of the service; and also, that same service
interface has one new MultiCore version, which is the one
that is being called from the UI.  Did I understand it right?

I assume you have multiple GDBControlDMContext, one for each
of your gdb-core combinations.  How do you originally create
all the different contexts for these different GDBs?

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