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