Re: [cdt-debug-dev] MI-debugger for embedded applications

[Burkhard Kirchner <kirchner@xxxxxxxxx>]

> > Unfortunately i couldn't insert the load command in the GDB command file
> > (dosn't work). Moreover that would be long winded.
> > Hence I wrote a new class "MILoad" and inserted it into the
> >     createLaunchSession() method in the
> >     GDBServerCDIDebugger class after the invocation of TargetSelect.
>
> Why not making your own launcher doing the extra steps.
> There are examples plugin in the archive on how to do this.

That's My intentions.

> > Then the debugger was running but during the termination of the debug
> > process the application was hanged.
> >
> > The first reason was the line:
> >       session.postCommand0(abort, -1); // do not wait for the answer.
> > in  MIInferior: terminate()
> >
> > I've replaced it by session.postCommand() with a wait for the answer.
> > Otherwise CDT got the answer later and was totally confused.
> > What is the sense of "no wait for answer"?
>
> It is a very long discussion with Oyvind spawning across lots of PR.
> But basically, the rationale is; the users have finish the debug session
> and there is no reason to synchronize with the "abort" command and if it
> fails (and it does many times, for x reasons, gdb can not kill the
> inferior) we still go through the termination sequence  and exit GDB.

Without waiting, the GDB executes the "abort" command and gives an answer. The 
next "postCommand()" reads this answer with a invalid sequence number. Then 
the terminate method doesn't run successful.
If the "abort" command was launched with "postCommand()" and a suitable 
timeout, the termination sequence should continue even if the "abort" command 
fails.

>
> > Another problem is the terminate() method in MISession.
> > After the call of "postCommand0(exit, 2000)", eclipse hangs totally.
> > I don't now why, but the problem dosn't occur with a "Thread.sleep(2000)"
> > before the "postCommand()"
>
> Are you using Windows ?

I'm using NOVELL/SUSE Linux 9.1. It's faster then Windows with cygwin.


>
> > Which way do you prefer for future development of the CDT-debugger? A
> > dedicated embedded debugger plugin or the enhancement of the MI debugger
> > interface?
>
> Both ...
> Make a private plugin and for fixes that should be in the general common
> MI base code;  a PR with a patch and the rationale.

O.k. I'll do so.

>
> For example what you describing above seems to be general problems but
> experience tells us, it may be specific to your version of gdb 8-(
> Not all ports of gdb are equal.
>

Burkhard Kirchner

FALCOM