Re: [patch/ob] not_a_breakpoint -> not_a_sw_breakpoint

[Andrew Cagney <ac131313 at ges dot redhat dot com>]

> > The variable is used vis:
> >
> > bpstat_stop_status (CORE_ADDR *pc, int not_a_sw_breakpoint)
> > {
> > [...]
> >    /* Get the address where the breakpoint would have been.  The
> >       "not_a_sw_breakpoint" argument is meant to distinguish between a
> >       breakpoint trap event and a trace/singlestep trap event.  For a
> >       trace/singlestep trap event, we would not want to subtract
> >       DECR_PC_AFTER_BREAK from the PC. */
> >
> >    bp_addr = *pc - (not_a_sw_breakpoint && !SOFTWARE_SINGLE_STEP_P () ?
> >                     0 : DECR_PC_AFTER_BREAK);
> >
> >
> > Later in the code appears:
> >
> >            if (DECR_PC_AFTER_HW_BREAK != 0)
> >              {
> >                *pc = *pc - DECR_PC_AFTER_HW_BREAK;
> >                write_pc (*pc);
> >              }
> >
> > if not_a_sw_breakpoint applied to hardware breakpoints then the above 
> > decrement would be guarded by not_a_sw_breakpoint.
> >
> > BTW, an even more correct name is ``not_a_sw_breakpoint_trap''. 
> > However, Joel might end up adding something better than that.
>
> Your reasoning is sound so long as we assume that the code
> that you're basing your reasoning on isn't bitrotted.  (I only see
> one target with a non-zero DECR_PC_AFTER_HW_BREAK, and I'll bet that
> hasn't been tested in a while.)
I think that is separate.  The ``intent'' of the variable is to indicate 
that what is being looked at isn't a trap due to a software breakpoint 
event.

> What I'd like to be convinced of is that the conditions which are
> used to instantiate ``not_a_sw_breakpoint'' really imply that that
> we could be stopped due to a hardware watchpoint, but not a software
> breakpoint trap.
>
> The conditions in question are:
>
>     currently_stepping (ecs) && prev_pc != stop_pc - DECR_PC_AFTER_BREAK
Yes, see my e-mail to Joel.  I'm asking that a separate explict 
``trap_from_software_singlestep'' be ||ed into those equations. While 
the rest might be pretty bogus (the above is just an heuristic really) 
at least that flag will be correct :-)

Andrew