Re: [PATCH] Fix displaced stepping for remote targets

[Luis Gustavo <luis_gustavo at mentor dot com>]

On 04/09/2012 02:45 AM, Yao Qi wrote:
> On 03/21/2012 04:33 AM, Luis Gustavo wrote:
> > If a target can't use hw single-stepping to execute instructions in the
> > scratch pad, i think it should disallow it by returning 0 in
> > gdbarch_displaced_step_hw_singlestep. Does it make sense?
>
> Yes, that is what gdbarch_displaced_step_hw_singlestep for, AFAIK.  I am
> sorry I don't understand how gdbarch_displaced_step_hw_singlestep
> related to your patch here.

It is not directly related. I raised that one based on your comment 
about some targets not being able to HW single-step a group of 
instructions in the scratch pad. In that case, they should report 0 for 
gdbarch_displaced_step_hw_singlestep.

My target reports 1 for gdbarch_displaced_step_hw_singlestep, and thus 
HW single-stepping should be used when doing displaced stepping.

The patch addresses a different problem, namely the overriding of the 
STEP variable's value (originally containing 
gdbarch_displaced_step_hw_singlestep ()'s result) with this call...

if (step && breakpoint_inserted_here_p (aspace, pc))
            step = 0;

If we are trying to step-over a breakpoint using displaced stepping, 
breakpoint_inserted_here_p (aspace, pc) will obviously return true, thus 
we disable stepping by setting it to 0. This looks wrong.

This has the effect of issuing a vCont;c packet to the remote target 
instead of vCont;s.

By changing the order of the statements in the code, we address this in, 
hopefully, the correct way. Unless there is some magic going on there.

Regards,
Luis