On Wed, Jun 3, 2020 at 11:10 AM Will Deacon <will@xxxxxxxxxx> wrote: > > Luis reports that, when reverse debugging with GDB, single-step does not > function as expected on arm64: > > | I've noticed, under very specific conditions, that a PTRACE_SINGLESTEP > | request by GDB won't execute the underlying instruction. As a consequence, > | the PC doesn't move, but we return a SIGTRAP just like we would for a > | regular successful PTRACE_SINGLESTEP request. > > The underlying problem is that when the CPU register state is restored > as part of a reverse step, the SPSR.SS bit is cleared and so the hardware > single-step state can transition to the "active-pending" state, causing > an unexpected step exception to be taken immediately if a step operation > is attempted. We saw this issue also and worked around it in user-space [1]. That said, I think I'm ok with this change in the kernel, since I can't think of a particularly useful usecase for this feature. However, at the same time as changing this, we should probably make sure to enable the syscall exit pseudo-singlestep trap (similar issue as the other patch I had sent for the signal pseudo-singlestep trap), since otherwise ptracers might get confused about the lack of singlestep trap during a singlestep -> seccomp -> singlestep path (which would give one trap less with this patch than before). Keno [1] https://github.com/mozilla/rr/blob/36aa5328a2240dc3d794c14926e0754f66ee28e0/src/Task.cc#L1352-L1362
