Re: [patch/ob] not_a_breakpoint -> not_a_sw_breakpoint

[Andrew Cagney <ac131313@ges.redhat.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