This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
inferior stop events
- To: <gdb at sources dot redhat dot com>
- Subject: inferior stop events
- From: Keith Seitz <keiths at cygnus dot com>
- Date: Wed, 6 Jun 2001 10:36:01 -0700 (PDT)
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