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

[Pedro Alves <pedro at codesourcery dot com>]

On Wednesday 18 November 2009 16:59:53, Jan Kratochvil wrote:
> On Wed, 18 Nov 2009 15:45:38 +0100, Pedro Alves wrote:
> 
> >        if (ecs->event_thread->stop_signal == TARGET_SIGNAL_TRAP)
> >  	ecs->random_signal
> >  	  = !(bpstat_explains_signal (ecs->event_thread->stop_bpstat)
> > +	      || stopped_by_watchpoint
> >  	      || ecs->event_thread->trap_expected
> >  	      || (ecs->event_thread->step_range_end
> >  		  && ecs->event_thread->step_resume_breakpoint == NULL));
> 
> This means forgotten triggers (as currently without the hw-watchpoints
> patch 1/4) would be hidden.

But is that a correctness problem?  I guess I could put something like:

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.

> As the is already the infrastructure for moribund locations isn't it better to
> enable them even for all-stop mode and check the address explicitly against
> them?  Sorry for no such patch in this mail.

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.

-- 
Pedro Alves