[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [cdt-dev] Handling multi core in DSF Services.
|
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
>
>