Re: [cdt-debug-dev] Remote debugging

["Alain Magloire" <alain@xxxxxxx>]

> 
> > Maybe this sort of functionality is better suited to an Eclipse =
> "feature,"=20
> > rather than a patch to the current debug code?  (it's a genuine =
> question, not a=20
> > rhetorical one)
> 
> Actually, I've got it implemented as a feature right now.  That's led to =
> one
> or two problems, and it would be easier all around if the basic =
> functionality
> was integrated with the other C debugging work.
> 
> The initial patch would be pretty slim:  add public methods to the =
> ICDISession
> and ICDITarget interfaces to support establishing a remote connection =
> with the
> debug server, add a method to the CDebugModel for creating a new remote
> debug target, and add a few MI command classes.
> 

Why would you do it a this level?  At first glance without too much
thinking, I would extend the Launcher (core, attach etc ..) for
one more "remote" and create a new ICDISession.

ICDISession createRemoteSession(..., String hostname, long port) {
	MICommand cmd = new MITargetSelect(..);
	MICommand cmd = new MITargetUpload(..);
 	...
	retunr cdiSession;
}

See the mi.core plugin, mi/core/GDBDebugger.java

> Right now, I'm passing remote connection parameters as a String[].  That =
> works
> for me, but I'm open to other suggestions (an interface to describe =
> target
> connection interface, for example.)
> 

An interresting question, What is a "Target/Hostname" in eclipse and how to represent it.
To make things easier I would prefer the user be presented with a view, a tree containning
a list of the potential "targets" on the network.  You would also want to query the targets
to get the architecture, obviously you do not want to debug an x86 program on Mips board etc ..
All sort of nice possibilities if we have an interface defining what is a "target".


> The intent is to add the core changes needed to support adding remote =
> debugging
> feature(s) at some time in the future.
> 

Understood.
Maybe the description of the "target" would be better of out
of the debugger ICDI* API and more generic to allow other possibilities.

> > I haven't had a chance to get my hands dirty with any of the Eclipse =
> internals=20
> > yet, but maybe this is a good place to start.  Can I help?
> 
> Phew!  I can think of easier places to start :-)  If it wasn't for the =
> find command
> in Eclipse, I think I'd still be trying to understand how it all fit =
> together.
> 

8-)
Eclipse plugin architecture can be difficult, there are however some
good docs on the subject.  The CDT by itself is not so complex.