Re: [cdt-debug-dev] Re: [cdt-patch] MISession terminate patch

["Alain Magloire" <alain@xxxxxxx>]

> 
> I realise that all the patch does is buy me a couple of secs, and it's
> more a stopgap solution than a proper fix. How would you go about
> ensuring events like Target TERMINATED or Target DISCONNECTED go through
> reliably?=20
> 

The MI plugin was frame to work asynchronously i.e. it was meant
to work as an event driven model.  So we have 3 threads
RxThread, TxThread and EventThread.

The RxThread blocks reading gdb outputs and as soon as a request response
comes back, it is parse/massage to some event/response and added to the event queue.
The EventThread will wake up and process the queue.

But for crucial events like(Target exiting or session exiting)
we should notify the listener right away(not going through the event queue)
	MISession.notifyObserver(event);
Or if we do not want to be stuck the observer callbacks,
create a Job/thread to process the listeners.

> > Questions:
> > Did you have a PR for this ?
> Not yet.=20
> 

Let me know and reassign to me.  So lets make this for head and branch.

> > Is this happen for you only when doing remote/attach ?
> Yes - we have gdbserver running on hardware.
> 
> > Is the abort/kill succesfull ?
> When it gets through to the target successfully, then yes.
> 
> > Note, I'll happily apply corrections to head and 2.1 branch but for
> the branch do not expect any release soon.

> When are corrections likely to be applied to the head/2.1 branch? =20
> 

In the past we have accomodate ISVs by applying patches and making fixes
as long as possible before the branch becomes stale.
But my point is:  even if we put fixes in the 2.1 branch, it does not mean
a 2.1.2 CDT is in the works(Unless somebody wants to commit to it,
like for CDT-2.1.1).

So make the PR and the fix will be apply to head and branch.

> I'm also occasionally seeing cases (also when running on a remote
> target), where it's failing to terminate a running target. What tends to
> happen, is that when the target is running, selecting Thread[Running]
> and terminating that results in gdbserver terminating (reflected in the
> debug display window), but nothing else happens. The thread continues
> running as if nothing happened.  After that, if i select the launch, and
> try to terminate, gdb will either eventually die after a long delay (10
> secs or so - timeout value?), or the debug window thinks that it's dead
> and the launch terminates but the actual gdb process remains active (and
> never dies). GDB console shows that a kill has been sent, but the last 2
> lines in the console are "mi_cmd_stack_info_depth: No stack". When
> debugging the runtime-workbench, it showed that MISession.terminate() is
> never called so the "-gdb-exit" command never gets posted. I don't know
> if this is a related issue or not.  Any thoughts?
> 

Many, the problem is gdb 8-) ... that was easy.

One possibility:
When the Target(Inferior) is running, gdb is non-responsive to 
any commands.  The only way to get gdb's attention is to suspend the target,
meaning dropping a SIGINT on gdb. This may or may not work or may work
with some delay.

gdb as a new option --async, for remote, for this option gdb is doing a select(2)/poll(3)
and still be responsive to command inputs.  So we will be able to use commands like:
	--exec-interrupt

but ... it does not work.

If you have more inputs on this, I would like to hear form it and work on possible
solutions.