[RFC] Inferior events vs update/busy/idle

[Keith Seitz <keiths at redhat dot com>]

Hi,

I'd like to talk briefly about inferior event notification...

As you know, today GDB event notification occurs primarily via four
hooks:

gdb_busy_hook   (now GDBEventHandler::busy)
gdb_update_hook (now GDBEventHandler::update)
gdb_idle_hook   (now GDBEventHandler::idle)
gdb_no_inferior_hook

Anyone who has ever worked on Insight knows that these distinctions are
simply not enough. Even worse, the meanings are slightly overloaded...

gdb_busy_hook/GDBEventHandler::busy is meant to be called/posted whenever
anything in the GUI (usually the update hook of a window) does something
which interacts with the target. It's main side effect is to disable the
GUI so that the user cannot, for example, open another window which will
start to communicate with the GUI.

gdb_idle_hook/GDBEventHandler::idle is called/posted when a window has
finished interacting with the target. It's main side effect is to enable
the GUI for input from the user. Unfortunately, calls to gdbtk_idle and
gdbtk_busy are not always symmetrical: there are various gdbtk_idle calls
scattered about.

gdb_update_hook/GDBEventHandler::update is called when the "current"
execution context has changed. In other words, the GUI's view of the
target was changed. All windows must update their views of the world, too.
This can happen if the PC changes (by running the target or because the
user changed it), if the user is browsing stack frames, or if the user
changes the "current thread", etc.

gdb_no_inferior_hook is currently called by gdbtk_idle. Whenever an idle
event is posted and there is no inferior (or not connected to a target),
the no_inferior_hooks are run. The hook is supposed to tell all
windows/widgets to reset themselves to a non-running state., e.g., the
control buttons on the toolbar should be disabled.

I would like to discuss tweaking this a litte. I have added an event
notification to infrun.c's print_stop_reason. I have exported "enum
inferior_stop_reason" so that others can use it, too.

Thus, we can now receive notification from (what used to be called)
wait_for_inferior on these events:

enum inferior_stop_reason
{
  /* We don't know why. */
  STOP_UNKNOWN,
  /* Step, next, nexti, stepi finished. */
  END_STEPPING_RANGE,
  /* Found breakpoint. */
  BREAKPOINT_HIT,
  /* Inferior terminated by signal. */
  SIGNAL_EXITED,
  /* Inferior exited. */
  EXITED,
  /* Inferior received signal, and user asked to be notified. */
  SIGNAL_RECEIVED
};

All of these offer an integer info parameter, which tells us, for example,
the exit status of the inferior or the signal received.

As you can see, these map on to our current hooks/events:

STOP_UNKNOWN (we'll never actually get this: print_stop_reason will call
internal_error before passing this to us)

END_STEPPING_RANGE->UpdateEvent

BREAKPOINT_HIT->UpdateEvent

SIGNAL_EXITED->UpdateEvent, gdb_no_inferior_hook

EXITED->UpdateEvent, gdb_no_inferior_hook

SIGNAL_RECEIVED->UpdateEvent

All of the UpdateEvent's generated above are a result of our current
algorithm, in which we call:

  gdbtk_busy
  # do the step, next, continue/run, stepi, nexti
  gdbtk_update
  gdbtk_idle

We could lose this "algorithm" entirely and rely on gdb to give us most of
these from the inferior_stop_event. (Of course, we would still need to be
told we were "executing", but that's a different patch!)

I think that doing so would bring us one step closer to getting rid of
gdbtk_call_command and relying on gdb to tell us when the target is
running, and when (and, finally, _why_) it stopped. Don't even get me
started on how this would simplify the whole gdb_running and
SrcWin::set_execution_status mess.

So, I am eliciting opinions in two areas:
1) Do you like/not like this change in thinking or am I in space?
2) I plan to get rid of UpdateEvent entirely, replacing it with
   an "InferiorStopEvent", which will give the details of the stop.
   (the data from print_stop_reason) This info will be passed as
   an event, so now ALL windows will know exactly why we stopped. Of
   course, most windows will not care (the Src[Text]Wins being the big
   exeception).

Comments?
Keith