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
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 Service
Hi 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