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

[Pedro Alves <pedro at codesourcery dot com>]

On Wednesday 18 November 2009 18:39:17, Jan Kratochvil wrote:

> 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.

I'd bet a couple of those are actually exactly as the all-stop case
I described and actually fixed by this change.

> > 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.

"indefinitely exactly until" is contradictory. :-)

Think about it.  The fact that we count a certain made-up number of events
_is_ part of the heuristic.  I've seen the moribund events count reaching
zero sooner than it should have, and GDB reporting a random
SIGTRAP by mistake.

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

If we have moribund watchpoint locations, then most of the races
you're talking about would still be hidden, exactly by the moribund
locations.  I don't think we'd be stricter.  It seems the only case that
wouldn't happen is the case of the target keeping reporting bad SIGTRAPs
repeatedly, but I'm sure those are noticeable by other symptoms,
like, e.g., target slowness.

Keep in mind that on targets that can't report a stopped data
address, gdb already necessarily ignores bad watchpoint traps.

-- 
Pedro Alves