Re: [PATCH v5 2/2] arm64: kgdb: Set PSTATE.SS to 1 to re-enable single-step

From: Will Deacon
Date: Fri Jan 27 2023 - 07:03:18 EST


On Mon, Dec 19, 2022 at 03:54:52PM +0530, Sumit Garg wrote:
> Currently only the first attempt to single-step has any effect. After
> that all further stepping remains "stuck" at the same program counter
> value.
>
> Refer to the ARM Architecture Reference Manual (ARM DDI 0487E.a) D2.12,
> PSTATE.SS=1 should be set at each step before transferring the PE to the
> 'Active-not-pending' state. The problem here is PSTATE.SS=1 is not set
> since the second single-step.
>
> After the first single-step, the PE transferes to the 'Inactive' state,
> with PSTATE.SS=0 and MDSCR.SS=1, thus PSTATE.SS won't be set to 1 due to
> kernel_active_single_step()=true. Then the PE transferes to the
> 'Active-pending' state when ERET and returns to the debugger by step
> exception.
>
> Before this patch:
> ==================
> Entering kdb (current=0xffff3376039f0000, pid 1) on processor 0 due to Keyboard Entry
> [0]kdb>
>
> [0]kdb>
> [0]kdb> bp write_sysrq_trigger
> Instruction(i) BP #0 at 0xffffa45c13d09290 (write_sysrq_trigger)
> is enabled addr at ffffa45c13d09290, hardtype=0 installed=0
>
> [0]kdb> go
> $ echo h > /proc/sysrq-trigger
>
> Entering kdb (current=0xffff4f7e453f8000, pid 175) on processor 1 due to Breakpoint @ 0xffffad651a309290
> [1]kdb> ss
>
> Entering kdb (current=0xffff4f7e453f8000, pid 175) on processor 1 due to SS trap @ 0xffffad651a309294
> [1]kdb> ss
>
> Entering kdb (current=0xffff4f7e453f8000, pid 175) on processor 1 due to SS trap @ 0xffffad651a309294
> [1]kdb>
>
> After this patch:
> =================
> Entering kdb (current=0xffff6851c39f0000, pid 1) on processor 0 due to Keyboard Entry
> [0]kdb> bp write_sysrq_trigger
> Instruction(i) BP #0 at 0xffffc02d2dd09290 (write_sysrq_trigger)
> is enabled addr at ffffc02d2dd09290, hardtype=0 installed=0
>
> [0]kdb> go
> $ echo h > /proc/sysrq-trigger
>
> Entering kdb (current=0xffff6851c53c1840, pid 174) on processor 1 due to Breakpoint @ 0xffffc02d2dd09290
> [1]kdb> ss
>
> Entering kdb (current=0xffff6851c53c1840, pid 174) on processor 1 due to SS trap @ 0xffffc02d2dd09294
> [1]kdb> ss
>
> Entering kdb (current=0xffff6851c53c1840, pid 174) on processor 1 due to SS trap @ 0xffffc02d2dd09298
> [1]kdb> ss
>
> Entering kdb (current=0xffff6851c53c1840, pid 174) on processor 1 due to SS trap @ 0xffffc02d2dd0929c
> [1]kdb>
>
> Fixes: 44679a4f142b ("arm64: KGDB: Add step debugging support")
> Co-developed-by: Wei Li <liwei391@xxxxxxxxxx>
> Signed-off-by: Wei Li <liwei391@xxxxxxxxxx>
> Signed-off-by: Sumit Garg <sumit.garg@xxxxxxxxxx>
> Tested-by: Douglas Anderson <dianders@xxxxxxxxxxxx>
> ---
> arch/arm64/include/asm/debug-monitors.h | 1 +
> arch/arm64/kernel/debug-monitors.c | 5 +++++
> arch/arm64/kernel/kgdb.c | 2 ++
> 3 files changed, 8 insertions(+)
>
> diff --git a/arch/arm64/include/asm/debug-monitors.h b/arch/arm64/include/asm/debug-monitors.h
> index 7b7e05c02691..ce3875ad5cd3 100644
> --- a/arch/arm64/include/asm/debug-monitors.h
> +++ b/arch/arm64/include/asm/debug-monitors.h
> @@ -104,6 +104,7 @@ void user_regs_reset_single_step(struct user_pt_regs *regs,
> void kernel_enable_single_step(struct pt_regs *regs);
> void kernel_disable_single_step(void);
> int kernel_active_single_step(void);
> +void kernel_regs_reset_single_step(struct pt_regs *regs);
>
> #ifdef CONFIG_HAVE_HW_BREAKPOINT
> int reinstall_suspended_bps(struct pt_regs *regs);
> diff --git a/arch/arm64/kernel/debug-monitors.c b/arch/arm64/kernel/debug-monitors.c
> index 3da09778267e..9af898b22ed4 100644
> --- a/arch/arm64/kernel/debug-monitors.c
> +++ b/arch/arm64/kernel/debug-monitors.c
> @@ -438,6 +438,11 @@ int kernel_active_single_step(void)
> }
> NOKPROBE_SYMBOL(kernel_active_single_step);
>
> +void kernel_regs_reset_single_step(struct pt_regs *regs)
> +{
> + set_regs_spsr_ss(regs);
> +}

Just a nit on the naming here, but please can this be
kernel_rewind_single_step() instead? I think it's closer to the rewind
function we have for user tasks than the reset function.

Cheers,

Will