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

[Abeer Bagul <abeer4eclipse@xxxxxxxxx>]

Hi,
 

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?

Suppose it is a two core launch, then it has a MultiCoreServicesLaunchSequence, which extends from ServicesLaunchSequence. This multicoreSLS then creates one object of multicoreservice for each service interface. 
So for the ICommandControlService, there is a multicore service object. In the doInitialize() method of this multicoreservice object, it does not delegate to the super.doInitialize(). Instead here we create N corespecific service objects for N cores, each object implementing the service interface. So for the multicore control service object, GDBControlDMContext object is not created. The multicore service object calls the initialize() method on each corespecific service object, which ends up in GdbControl.initialize(), N times.
So for the N corespecific service objects, N GDBControlDMContext objects are created.

Each core in the launch has a coreName, which is typed by the user, such as "controller", "dsp", "smp0", etc. This coreName is set as the ID of each GdbBackend corespecific service. Thus when each GDBControlDMContext object is created, its commandControlID is the semantic name of the core it represents.

Thanks,
Abeer 
Tensilica India