[RFC] Inferior stop events

Keith Seitz keiths@cygnus.com
Fri Jun 15 07:38:00 GMT 2001


On Thu, 14 Jun 2001, Andrew Cagney wrote:

> I think everyone agreed this was wrong long ago.  It should be:
>
>
> 	GDB Internals -> message -> Insight
> 	   |                           |
> 	   -------- Event Loop ---------
>
>
> That is, instead of Insight sitting on top of GDB processing stuff
> instantly, Insight would sit adjacent to GDB, allow GDB to complete its
> processing and *then* start processing any events it has outstanding.

This is exactly what I have proposed. All of gdb-events.sh's "events" can
act as either hooks or real, queued events. Right now I am using them as
hooks, but it has always been my plan to export those events into the Tk
event loop.

> In such a model, I don't think any (or very few) hooks are needed.
> Insight can find out the stop reason by asking GDB (just like MI did).
> All GDB needs to do is tell insight that the program state changed.

That is correct. I've been whacking all the hooks and inserting event
notifications.

I cannot find where mi asks for state information, could you point it out?
As far as I can tell, MI relies on some annotated output from
print_stop_reason.

I'll keep looking for the MI implementation of this...
Keith




More information about the Gdb mailing list