[RFA] Support moribund breakpoint locations.
Daniel Jacobowitz
drow@false.org
Thu Jun 5 16:11:00 GMT 2008
On Fri, May 02, 2008 at 09:11:08PM +0300, Vladimir Prus wrote:
>
> Dan,
> this is a repost of a patch from December; all dependencies are now
> in, and this version is fresh against HEAD. The behaviour has not
> changed the slightest bit, as far as I know.
>
> - Volodya
>
> * breakpoint.c (moribund_locations): New.
> (bpstat_stop_status): Process moribund locations.
> (update_global_location_list): Add removed
> locations to moribund_locations.
> (breakpoint_retire_moribund): New.
> * breakpoint.h (struct bp_location): New field
> events_till_retirement.
> (breakpoint_retire_moribund): Declare.
> * thread.c (thread_count): New.
> * infrun.c (handle_inferior_event): Call
> breakpoint_retire_moribund.
> * gdbthread.h (thread_count): Declare.
This is OK, but please replace a bunch of () with (void).
> + /* This location was removed from the targets. In non-stop mode,
> + a race condition is possible where we've removed a breakpoint,
> + but stop events for that breakpoint are already queued and will
> + arrive later. To suppress spurious SIGTRAPs reported to user,
> + we keep this breakpoint location for a bit, and will retire it
> + after we see 3 * thread_count events.
> + The theory here is that reporting of events should,
> + "on the average", be fair, so after that many event we'll see
> + events from all threads that have anything of interest, and no
> + longer need to keep this breakpoint. This is just a
> + heuristic, but if it's wrong, we'll report unexpected SIGTRAP,
> + which is usability issue, but not a correctness problem. */
I think it's a correctness issue on DECR_PC_AFTER_BREAK targets, since
if we don't know there was a breakpoint there, we won't know to back
up the PC. But I don't ever expect this to trigger.
--
Daniel Jacobowitz
CodeSourcery
More information about the Gdb-patches
mailing list