Hi Keno, Thanks for having a look. On Wed, Jun 03, 2020 at 11:42:46AM -0400, Keno Fischer wrote: > 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). Hmm, I don't completely follow your example. Please could you spell it out a bit more? I fast-forward the stepping state machine on sigreturn, which I thought would be sufficient. Perhaps you're referring to a variant of the situation mentioned by Mark, which I didn't think could happen with ptrace [2]. Cheers, Will [2] https://lore.kernel.org/r/20200531095216.GB30204@willie-the-truck
