[RFC] Inferior stop events

[Andrew Cagney]

> 2) It's not an event source! It posts no events to the event queue...
> 
> Even if we could put some sort of event posting into
> inferior_event_handler, we're STILL missing reasons for the stop, which
> (was) already known by the time this function is called.


For an async target, MI returns to the event-loop, at some later stage, 
GDB notifies MI that the target has stopped via the function 
mi_exec_async_cli_cmd_continuation() which was registered using 
add_continuation(). It is simply unfortunate that, for synchronous 
targets it uses another more nasty mechanism (fakeing asynchronous 
behavour).


> I'm sorry, but I just don't see how this conflicts with what I've done.
> IMO, gdb-events.sh and my proposed change is correct (or is at least
> closer to being correct). What MI does (print_stop_reason modification) is
> wrong. It does not generate an event, which is not hard to believe, given
> that MI is really not event driven. It's just another command line with
> different input/output syntaxes.


MI (ui-out, ui-filek, libgdb, event hooks, ...) is an architecture.  The 
top level happens to look like ``just another command line with 
different input/output syntaxes''.

Anyway, there is a far more important and underlying issue here. Insight 
needs to start putting some distance between its self and GDB - it can 
no longer assume certain GDB internals.  Knowing this needed to happen 
was one of the motivations behind the MI design.

With that in mind.  The only messages/events I'd expect GDB to send to 
clients are very simple vis:

	o	target busy
	o	target ready

longer term that might get expanded into:

	o	thread created/running/stopped/dead

The important thing is that GDB provides the absolute minimum of 
information and certainly not internal details.  The assumption is that 
the client will then, later, extract the details it needs from GDB using 
a ``libgdb/ui-out'' query.

As an example, look at the breakpoint interface.  The breakpoint events 
(created, changed, deleted) only include the breakpoint number.  It is 
assumed that the client will (when GDB is idle) extract the details 
using gdb_breakpoint_query() and a ui-out builder.

In the case of insight, it could use the above.  Alternativly, it could 
implement the more robust model:

   GDB                 event handler            insight
          -> stopped ->       |
          -> started ->       |
          -> stopped ->       |
                              |
     .-< stop-reason(uiout)? <'
     |
     `--> uiout = reason >----.
                              |
	                     `-> target-stop-event ->

The middle component (event hander) would, at it leasure, extract the 
stop reason from GDB and then pass it onto insight.

	Andrew