| RE: [dsdp-tm-dev] TM & Debug Service |
Hi, Martin,
Thanks for your help and advices!
What I most worry about is that taking debug as a service above the RSE(TM) is the right way ? Has anyone ever tried that?
Here is the Framework Diagram and Class Diagram for the Simulator, and Simulator debug Service Diagram with the discription.
1、 Target Management Framework
2、 the Simulator Debug Service Class Diagram
Description：
Here we take simulator connection as an example. We have a agent on simulator which provide the service such as debug, process. Look at the debug service agent, it works just like gdbserver/gdbstub.
When the IDE user select a connection from LaunchConfiguration UI Component, and want to debug an application on it, LaunchConfigurationDelegate will try to find out if this connection has the IDebugService interface. if yes, launch the method LanchForDebugging . and the LaunchForDebugging method has a sequence to take response to check , download , and launch the program on the selected connection. and then , Use the Debugger to take control of the remote running process . the ISimulatorDebugger is inherited and modified from ICDIDebugger2.
I have also studied the ppt you written "Component Based Launching (Launch Actions)" . you said that "There is a need for "scripts" to execute such complex launches". and I totally agree with you. Indeed I implement such "script" as java code.
发件人: Oberhuber, Martin [mailto:
Martin.Oberhuber@xxxxxxxxxxxxx]
发送时间: 2007年1月19
日 16:59
收件人: Target Management
developer discussions
主题: RE: [dsdp-tm-dev] TM
& Debug Service
Hello Jingxion,
Your approach sounds perfectly reasonable.
I'd probably use much fewer plugins for what you're trying to
accomplish, since I don't quite see the value of such plugin
separation but it slows down Eclipse startup if you have too
many plugins. For RSE itself, we're also working towards
reducing the number of plugins. For you, I'd rather choose
com.***.tm.debug.[core,ui] for the core debug service which you may use for either simulator or other agents
com.***.tm.simulator.[core.ui] for the simulator.
But, if you already defined the plugins of course you can live
with this for now -- lumping them together at a later point is
always easier than splitting it up later on, so you could keep
them separate until you see any issues (performance or other).
I'm not sure what kind of functionality your debug subsystem
would provide to the TM / RSE view. Sketching out the interface
of your IDebugService would probably help me to understand.
"Perform the debugging operation" is not sufficient for me to
understand.
With respect to Examples, we currently have the tutorial "team
subsystem" example, can you be more specific about your
needs? The problem with tutorial examples is that they need
to be self-contained and/or use open source technology that's
readily available for everybody. Most other debugging solutions
are proprietary. Do you have an idea how your specific needs
could translate into an example that can be ran by everybody?
Thanks,
--
Martin Oberhuber
Wind River Systems, Inc.
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
From: dsdp-tm-dev-bounces@xxxxxxxxxxx [mailto: dsdp-tm-dev-bounces@xxxxxxxxxxx] On Behalf Of Jingxiong Chen
Sent: Friday, January 19, 2007 3:35 AM
To: dsdp-tm-dev@xxxxxxxxxxx
Subject: [dsdp-tm-dev] TM & Debug ServiceHi All,
We are integrating RSE as our Target Management Solution.
We have an "Target Agent" on Simulator and, also the Target board. This Agent Provides kinds of connective functionalities and debug services for the Host tools.
Concerning about the Debug service, we decided to introduce the debug service as IDebugServiceSubSystem in RSE. In the LaunchDelegrate, we use the IHost to find out if the connection has the IDebugServiceSubSystem, and then use IDebugServiceSubSystem.Connect() to perform the connecting operation, after that, we use the IDebugService.debug() which provided by the IDebugServiceSubSystem to perform the debugging operation.
Here are the plugins we extend the RSE:
Com.***.tm.services.debug : the service Interface of debug service.
Com.***.tm.subsystem.debug.core: the subsystem interface and abstract implement of the debug subsystem.
Com.***.tm.subsystem.debug.ui: the default subsystem ui imp
Simulator
Com.***.tm.connectorservice.simulator: the connector service of the simulator
Com.***.tm.services.simulator : all the services provided by simulator including processlist, shell,and debug.
Com.***.tm.simulator : extends the systemTypes extension point.
Com.***.tm.subsystem.files.simulator: the file service for simulator
Com.***.tm.subsystem.process.simluator: the process list service for simulator.
Com.***.tm.subsystem.shell.simulator: the shell service for simulator.
Com.***.tm.subsystem.debug.simluator: the debug service for simlulator.
Com.**.debug , Com.***.debug.ui : these plugins provides the implement of the debugger, and called by the "subsystem.debug.core" plugin.
I am wondering if this is the right way to use RSE? Can anyone point out the faults for us? Thanks!
Hi Martin, do you have any plan to provide some sample plugins to demonstrate such kind of questions faced by the RSE integrators? I have studied the remote CDT sample, but it don't seem to meet our needs , we want to encapsulate "how to launch the debug service though all kinds of connections", not to explicitly use the shellCommands such as remotecdt sample do.
Thanks Martin and all.
Jingxiong Chen