On Wed, Jun 3, 2020 at 11:10 AM Will Deacon will@kernel.org 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/...