inferior stop events

[Keith Seitz <keiths at cygnus dot com>]

Hi,

I am attempting to expand the UI event model with some sort of inferior
stop event to notify UI's that the inferior has stopped (and why). So far,
I am just stealing print_stop_reason's "enum inferior_stop_reason" as
possible explanations:

  STOP_UNKNOWN
  END_STEPPING_RANGE
  SIGNAL_EXITED
  EXITED
  BREAKPOINT_HIT
  SIGNAL_RECEIVED

Most of these are pretty straight-forward, but there are a few problems.
One problem: BREAKPOINT_HIT is not used anywhere.

After much playing around, I think that I may have (a starting point) for
where BREAKPOINT_HIT notification "should" go, but I need a little help
from the pros to determine if it is correct.

Right now, the command line relies on print_stop_reason to print out
(almost) everything except BREAKPOINT_HIT -- presumably because it is
done in normal_stop by calling bpstat_print.

At first, I inserted a notification right in front of bpstat_print, but
that doesn't seem to work too well, since at this point, we cannot tell
the difference between temporary breakpoints set by the user and those set
by gdb.

So I stepped through handle_inferior_event (ugh!) a few (thousand) times,
and tried putting a notification at infrun.c:2413:

	case BPSTAT_WHAT_STOP_NOISY:
	  stop_print_frame = 1;

	  /* We are about to nuke the step_resume_breakpoint and
	     through_sigtramp_breakpoint via the cleanup chain, so
	     no need to worry about it here.  */

	  inferior_stop_event (BREAKPOINT_HIT,
			       ((stop_bpstat != NULL
				 && stop_bpstat->breakpoint_at != NULL)
				? stop_bpstat->breakpoint_at->number : 0));

	  stop_stepping (ecs);
	  return;

When a user-installed breakpoint is hit, we get the breakpoint number. If
it is a gdb breakpoint, then we get 0. Does this look remotely correct?
This seems to work with stepping into/out of, setting temporary bps,
watches, etc.

Now, the overall goal is to be able to inform UIs that the target/inferior
has stopped, so it would seem that I need to insert notifications
EVERYWHERE stop_stepping is called. Does this sound right?

Of course, just looking through all the places where stop_stepping is
called, I can see that enum inferior_stop_event does not contain all the
cases that are needed, e.g., shared library events for which the user has
requested a stop, watchpoints, etc. So, would it be best for me to add
some new event types to enum inferior_stop_reason or should I would it be
preferred to define a new enumeration of events specifically for use by
UIs?

I am inclined to go with adding to enum inferior_stop_events, since it
seems to me, that print_stop_reason and this enum are really UI functions
implemented in gdb's backend (they exist for the command-line).

Am I off my rocker? (Of course, you can expect some followup on all the
cases where we call stop_stepping and I have no idea why!)

Keith