Re: [RFA] enable software single step on alpha-osf

[Joel Brobecker <brobecker@gnat.com>]

> Can you confirm that the code is encountering a situtation where both 
> breakpoints_inserted and singlestep_breakpoints_inserted_p are true.  I 
> think this occures when doing a single step after stepping off of a 
> breakpoint.  When single stepping off a breakpoint, only 
> singlestep_breakpoints_inserted_p would be true.
> 
> If this is the case then the comments should make mention of it.  It 
> also makes the re-ordered if statement part of the patch correct.

Yes, I can confirm this, and this should happen fairly often: suppose
you have inserted a regular breakpoint in your program, anywhere, and
then do a single step. Before resuming the inferior, GDB will re-insert
the breakpoints, and set breakpoints_inserted. At the same time, because
we are doing a s/w single step, singlestep_breakpoints_inserted_p will
be set too. Did I miss something?

As for the re-ordering, I made it because I saw some regressions in the
testsuite after switching to s/w single step.  Unfortunately, I don't
remember which ones, I would have to rerun the testsuite without this
change to find them again. But the following comment explains in which
cases the re-ordering was necessary:

      /* Check if a regular breakpoint has been hit before checking
         for a potential single step breakpoint. Otherwise, GDB will
         not see this breakpoint hit when stepping onto breakpoints.  */

> The second part of the change is more tricky:
>  +           stop_pc -= DECR_PC_AFTER_BREAK;
> Is it fixing any failures?  Software singlestep can be handled in two 
> different ways:
> - as a breakpoint
> - as a hardware single step
> and which is prefered decides if/when there should be a decrement.

Yes, this one is actually fixing most of the failures.

I made several attempts at fixing the regressions before coming with
this solution. This part of the code is quite tricky, and it seems to me
that treating single-step breakpoints as hardware single step is the
simplest way to handle them. I like this because the differences in
processing between software and hardware single-step become smaller.
See for instance the change in breakpoint.c which made the use of this
macro disappear from this file.

> Anyway, the thing I'm having trouble convincing myself that there can't 
> be a double decrement -- eg for a hardware watchpoint or similar.

I've tried as much as I can to make sure this can not happen, but I am
not familiar enough to have a good level of confidence in my analysis.
All I can say is: this patch fixes all the regressions observed in the
testsuite after switching to software single step. I know this is no
absolute proof, but that gives me a certain level of confidence.

-- 
Joel