From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: Keith Seitz Cc: Elena Zannoni , gdb@sources.redhat.com, insight Subject: Re: [RFC] Inferior stop events Date: Fri, 15 Jun 2001 13:44:00 -0000 Message-id: <3B2A73C8.5040106@cygnus.com> References: X-SW-Source: 2001-06/msg00146.html > 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