This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: hardware watchpoints in non-stop - "moribund"/delayed watchpoint traps

On Wed, 18 Nov 2009 18:50:50 +0100, Pedro Alves wrote:
> if (debug_infrun
>     && !bpstat_explains_signal (ecs->event_thread->stop_bpstat)
>     && stopped_by_watchpoint)
>   fprintf_unfiltered (gdb_stdlog,
>                      "infrun: no user watchpoint explains watchpoint event, ignoring");
> so that we can tell from the logs if something is reporting bad
> watchpoint SIGTRAPs.

The problem is it is not clear from this message there is a GDB bug and the
testsuite already contains too many racy failures to be catching more of them.

> At first I thought so, but, I then changed my mind into thinking the extra
> complexity isn't necessary.  We needed the moribund breakpoint locations
> heuristic, to be able to distinguish random SIGTRAPs from delayed software
> breakpoint traps.  We don't keep them indefinitly, so to reduce the
> chances of mistaking a real random SIGTRAP from a delayed software
> breakpoint SIGTRAP.  We don't need the heuristic with hardware watchpoint
> traps --- we can always tell the difference.

The heuristic can be disabled in the all-stop mode remembering all watchpoint
locations indefinitely exactly until count_events_callback() reports zero.

Still the moribund infrastructure is IMO suitable for this task.

But sure your patch is better than the current state and I can post what
I find more strict later.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]