Hi Abeer,
I have to admit that I hadn't imagined using the proxy pattern with
the services when we first designed the base interfaces, Toni
implemented something similar in our product and it works perfectly
well. I'm glad to hear that you came to the same conclusion.
Cheers,
Pawel
On 04/11/2011 04:36 AM, Abeer Bagul wrote:
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
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
|