| Message ID | 20200702212618.17800-1-will@kernel.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | arm64: Fix single-step handling | expand |
Hi Will, On 7/2/20 6:26 PM, Will Deacon wrote: > Hi all, > > This is version two of the patches I previously posted here: > > v1: https://lore.kernel.org/linux-arm-kernel/20200603151033.11512-1-will@kernel.org/ > > Thanks to Keno for a bunch of helpful feedback on that, which has led to > the following major changes for v2: > > - Use pseudo-step traps for both entering a signal handler and exiting a > system call. > > - Document our weird x7 behaviour with PTRACE_SYSCALL. > > It has to be said that I'm a bit nervous about these changes. I played > around with GDB and things seemed ok, but I would really appreciate it > if Luis could run the GDB testsuite with these changes applied. Thanks for working on this. I'll need some time to give this a go. I'll let you know what the results are. Do I only need to exercise the AArch64 state? Or would this impact AArch32 as well? Regards, Luis
Hi Luis, On Fri, Jul 03, 2020 at 07:52:34AM -0300, Luis Machado wrote: > On 7/2/20 6:26 PM, Will Deacon wrote: > > This is version two of the patches I previously posted here: > > > > v1: https://lore.kernel.org/linux-arm-kernel/20200603151033.11512-1-will@kernel.org/ > > > > Thanks to Keno for a bunch of helpful feedback on that, which has led to > > the following major changes for v2: > > > > - Use pseudo-step traps for both entering a signal handler and exiting a > > system call. > > > > - Document our weird x7 behaviour with PTRACE_SYSCALL. > > > > It has to be said that I'm a bit nervous about these changes. I played > > around with GDB and things seemed ok, but I would really appreciate it > > if Luis could run the GDB testsuite with these changes applied. > > Thanks for working on this. I'll need some time to give this a go. I'll let > you know what the results are. Brilliant, thank you. > Do I only need to exercise the AArch64 state? Or would this impact AArch32 > as well? I doubt AArch32 userspace goes very near PTRACE_SINGLESTEP, as it's not supported by arch/arm/, so AArch64 testing should be sufficient. Cheers, Will
Hi all, This is version two of the patches I previously posted here: v1: https://lore.kernel.org/linux-arm-kernel/20200603151033.11512-1-will@kernel.org/ Thanks to Keno for a bunch of helpful feedback on that, which has led to the following major changes for v2: - Use pseudo-step traps for both entering a signal handler and exiting a system call. - Document our weird x7 behaviour with PTRACE_SYSCALL. It has to be said that I'm a bit nervous about these changes. I played around with GDB and things seemed ok, but I would really appreciate it if Luis could run the GDB testsuite with these changes applied. Cheers, Will Cc: <kernel-team@android.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Luis Machado <luis.machado@linaro.org> Cc: Keno Fischer <keno@juliacomputing.com> --->8 Will Deacon (4): arm64: ptrace: Add a comment describing our syscall entry/exit trap ABI arm64: ptrace: Consistently use pseudo-singlestep exceptions arm64: Override SPSR.SS when single-stepping is enabled arm64: Use test_tsk_thread_flag() for checking TIF_SINGLESTEP arch/arm64/include/asm/debug-monitors.h | 2 ++ arch/arm64/include/asm/thread_info.h | 1 + arch/arm64/kernel/debug-monitors.c | 24 +++++++++---- arch/arm64/kernel/ptrace.c | 45 +++++++++++++++++++------ arch/arm64/kernel/signal.c | 11 ++---- arch/arm64/kernel/syscall.c | 2 +- 6 files changed, 59 insertions(+), 26 deletions(-)