Re: [patch] Use displaced stepping regardless of SW single step

[Pedro Alves <pedro at codesourcery dot com>]

On Sunday 04 September 2011 14:54:21, Yao Qi wrote:
> Hi,
> I noticed that I can only do displaced stepping in first `si`, and in 
> the following `si', displaced stepping is not used at all, as shown below,
> 
> (gdb) set displaced-stepping on
> (gdb) set debug displaced 1
> (gdb) si
> During symbol reading, incomplete CFI data; unspecified registers (e.g., 
> rax) at 0x400565.
> displaced: stepping process 32472 now
> displaced: saved 0x400482: 49 89 d1 5e 48 89 e2 48 83 e4 f0 50 54 49 c7 c0
> displaced: copy 0x400564->0x400482: 55 48 89 e5 48 83 ec 10 e8 ff fe ff 
> ff 89 45 fc
> displaced: displaced pc to 0x400482
> displaced: run 0x400482: 55 48 89 e5
> displaced: restored 0x400482
> displaced: fixup (0x400564, 0x400482), insn = 0x55 0x48 ...
> displaced: relocated %rip from 0x400483 to 0x400565
> 0x0000000000400565      24      {
> (gdb) si
> 0x0000000000400568      24      {
> (gdb) si
> 27        pid = fork ();
> 
> I don't think that is the expected behavior of gdb, so there may be 
> something wrong in gdb.  The displaced stepping is controlled by this 
> condition check,

But it is.  Displaced stepping is only necessary to step over breakpoints
(trap_expected) without removing them.  If there's no breakpoint at the
current instruction, we can just do a normal step.

> I don't figure out the reason we need to check software_single_step_p 
> here.  We could do displaced stepping for targets support software 
> single step, and we could do displaced stepping for HW single step as well.

From <http://sourceware.org/ml/gdb-patches/2009-06/msg00253.html>:

> > We still can't use software single-stepping simultaneously in multiple
> > threads.  Pedro, should we fix that or always use displaced stepping
> > for now?
> 
> It would be nice to have that fixed, for sure, so yes to the
> we should fix that question.  However, it seems to me that this
> is something that can be worked on mostly independently of the ARM
> bits as it's a general software single-step issue, not really ARM
> specific.  Unless someone wants to (and has time to) tackle it
> right now, I'd say go with the always displace-step version.  If
> nothing else, helps in stressing the displaced stepping
> implementation.  :-)

-- 
Pedro Alves