Hi,

While debugging a remote target that supports hardware single-stepping 
with a GDB that supports displaced stepping, i've ran into the following 
problem...

When reaching a breakpoint, GDB should take care of relocating the 
instruction underneath that breakpoint to the scratch space where it 
will be executed out-of-line.

If a target supports hw single-stepping for displaced stepping, GDB 
should just send a vCont;s packet to tell the target to step a single 
instruction. In my case, GDB was always sending a vCont;c instead.

I've tracked it down to infrun.c:resume, where we have this check:

       if (gdbarch_cannot_step_breakpoint (gdbarch))
         {
           /* Most targets can step a breakpoint instruction, thus
              executing it normally.  But if this one cannot, just
              continue and we will hit it anyway.  */
           if (step && breakpoint_inserted_here_p (aspace, pc))
             step = 0;
         }

My target can't step breakpoints and, if we're doing displaced stepping, 
it's because we're trying to step off a breakpoint, thus 
breakpoint_inserted_here_p returns true, and we disable single-stepping 
by setting step to 0.

It seems to me we need to update the PC prior to calling 
breakpoint_inserted_here_p since the displaced stepping machinery 
adjusted the old PC to point to the space in the scratch area. That way 
we can properly command the target to step the displaced instruction and 
we can check for breakpoints at the real execution place.

The following patch fixes this by pushing the if block further down in 
the code and taking care of updating PC if displaced stepping is being used.

I've regtested this on x86 and everything looks OK. This also makes GDB 
send vCont;s now.

Ok?

Luis