| RE: [dsdp-tm-dev] TM & Debug Service |
Sorry for the late reply.
As for your question under here:
Q: " How do you control the context e.g. set breakpoints etc? Would that go over a separate connection or would you try tunnelling all debugger requests through your agent?"
A: We have a agent on simulator, it runs over the combined protocol which defined by ourselves, and can be ported to the device. it takes all the responsibility of the the channel communication, and dispatch the data to the right service implementation, transfer the result to the host. So as for the debug, I think we must use the DSF, not just the existed CDT CDI interface, because the CDI interface does not meet these needs.
I have read every mail list content since two years ago, I noticed that , more and more people, ask the similar question: "how to combined CDT, Launching Framework, TM, and Debug together to run properly".
Our solution to this question is to abstract the debug as a subsystem of TM. And subsystem contains debug service. And if every connection has contained the debug subsystem, launch the it's service.
And I also noticed another mail "Guide to connect MIPS/ RISC using TM" ,you said that "To give you a concrete example of what can be done, Wind River is commercially implementing a "WR Debugger Subsystem" (impl of RSE ISubSystem) which can connect to multiple kinds of backend including VxWorks agent, Linux usermode-agent, Generic gdbserver (can be OS or OS-less) and Wind River ICE targets (without any OS)." . so I think we are doing the same thing.
"
Best regards.
Jingxiong Chen
发件人: Oberhuber, Martin
[mailto:Martin.Oberhuber@xxxxxxxxxxxxx]
发送时间: 2007年1月24
日 15:59
收件人: Target Management
developer discussions
主题: RE: [dsdp-tm-dev] TM
& Debug Service
Hello Jingxiong,
One important point of your design seems to be the multiplexing of the various services on a single, replaceable connection.
The ISimulatorDebugService you outline contains method for launching a debugger, and it seems to make use of other registered services (like shell, download etc) to perform its actions. Up to now, nobody that I'd know of has tried such an approach, but it seems to make some sense. The approaches that I know would directly use IHostShell, IShelLService, IFileService etc. in the ILaunchConfigurationDelegate and I'm not sure I can see the benefit of abstracting an ISimulatorDebugService just for launching. What I do not quite understand, is how your debugger would continue operation once the remote context is launched. How do you control the context e.g. set breakpoints etc? Would that go over a separate connection or would you try tunnelling all debugger requests through your agent?
In some previous face-to-face meetings, we have been discussing ideas of abstracting the actual debugger implementation (with abstract actions like singleStep, runTo, setBreakpoint etc that can be implemented differently by different debuggers). The device debugging project continues going that route with the Debugger Services Framework (DSF). For target management, we do not see these abstractions right now since they are too debugger centric. We see target management more as the mediator that allows discovering kinds of services which may be implemented by others.
That being said, tunnelling of arbitrary connections through a single multiplexed channel is an important use case for target management that has come up in several scenarios so far. We have not done any analysis or design work for that use case so far but it looks like we'll need to consider it for the future.
Regarding the Launch Action idea from my presentation, there's currently some interesting discussion on this list with Robert Norton. Feel free to join if you are interested.
Hope this helps - let us know if you have more questions.
Thanks,
Martin Oberhuber
Target Management Project Lead, DSDP PMC Member
From:
dsdp-tm-dev-bounces@xxxxxxxxxxx [mailto:
dsdp-tm-dev-bounces@xxxxxxxxxxx] On
Behalf Of jingxiong chen
Sent: Tuesday, January 23, 2007 8:22 AM
To: dsdp-tm-dev@xxxxxxxxxxx
Subject: 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