Re: [cdt-debug-dev] Adding a Target....

["Alain Magloire" <alain@xxxxxxx>]

> 
> Hi!
> 
> So here's the break down on how we got a custom target working for us on a 
> not quite golden version of 1.0.1. (Will move to golden here shortly.)

I've updated a few fixes on the stable CDT_1_0_1 branch that maybe
of interests:
- Binary Parser for *.a(Only show one symbols)
- search in the CEditor.

They are __not__ part of the CDT-1.0.1 release.
This more to help third parties
Some other fixes could probably be added cleanly, if requested.


.....
[good reading deleted]
.....

> To recap the interface, ICDebugger creates ICDISession which hasPart 
> ICDITarget. In the implementation GDBDebugger creates a CSession which 
> creates and makes available a CTarget.

Yes, you got the picture, ICDebugger is part of the extension-point:

for example, for Cygwin:

   <extension point="org.eclipse.cdt.debug.core.CDebugger">
      <debugger
            platform="win32"
            name="%CygwinGDBDebugger.name"
            modes="run,core,attach"
            cpu="native"
            class="org.eclipse.cdt.debug.mi.core.CygwinGDBDebugger"
            id="org.eclipse.cdt.debug.mi.core.CygwinCDebugger">
      </debugger>
   </extension>

The CygwinCDebugger creates the CDI session and away we go:

pubic class CygwinCDebugger implements ICDebugger {

	ICDISession createLaunchSession(...) {
		Process gdb = Runtime.getRuntime().exec("gdb -i mi1 ....");
		MISession mi = new MISession(gdb, ...);
		return new Session(mi, false);
	}
...
}

Lots of helper methods are provided in the MIPlugin to make things easier,
example MIPlugin.createMISession() etc ..

For a new implementation of CDISession i.e not based on gdb/mi, this
will be the entry point.

The second one is UI/Launch to provide some specifics UI controls.

   <extension point="org.eclipse.cdt.debug.ui.CDebuggerPage">
      <debugPage
            class="org.eclipse.cdt.debug.mi.internal.ui.CygwinDebuggerPage"
            id="org.eclipse.cdt.debug.mi.CygwinDebuggerPage"
            debuggerID="org.eclipse.cdt.debug.mi.core.CygwinCDebugger">
      </debugPage>
   </extension>

> There was one issue with the base class. I have no idea who uses 
> lastExecutionToken, but it is made available from CTarget. It's also 
> private with no set method.


GDB/MI when an interruption occured will resend the old token:

    (gdb)
    111-exec-continue
    111^running

    (gdb)
    222-exec-interrupt
    222^done
    (gdb)
    111*stopped,signal-name="SIGINT",signal-meaning="Interrupt",
    frame={addr="0x00010140",func="foo",args=[],file="try.c",line="13"}
    (gdb)

noticed that token 111 was reused for the OOB(stopped).

This is use by the breakpoint manager, if you try to set a breakpoint
while the target is running, it will try
- get the last token for running(111)
	Target.getLastToken();
- Tell the EventManger to ignore and OOB with token 111
	EventManager.disableEventToken(111);
- interrupt the running target
	Target.suspend();
- set the breakpoint
- resume the target
	Target.resume();

The token is use to tell the EventManager to ignore the 111 OOB, generated
by the suspend.


> So, that's how it ended up working. Interesting classes attached. There was 
> probably an easier way and I always like hearing about that.

Nice work!

I'm not sure about one thing, the extension of cdi.CTarget, could you
not just attach to the target when you were creating the session in
XtGDB.createCSession() ?
Now you are delaying this when Eclipse debug framework calls
Target.restart().