Re: [PATCH v3] gdb/arm: Handle lazy FPU register stacking

[Pedro Alves <pedro@palves.net>]

On 2022-09-27 8:09 p.m., Torbjörn SVENSSON via Gdb-patches wrote:
> Read LSPEN, ASPEN and LSPACT bits from FPCCR and use them for the
> first exception frame.  All frames after will always have the FPU
> registers on the stack, regadless if lazy stacking is active or
> inactive.  See "Lazy context save of FP state", in B1.5.7, also ARM
> AN298, supported by Cortex-M4F architecture for details on lazy FPU
> register stacking.  The same conditions are valid for other Cortex-M
> cores with FPU.
> 
> This patch has been verified on a STM32F4-Discovery board by:
> a) writing a non-zero value (lets use 0x1122334455667788 as an
>    example) to all the D-registers in the main function
> b) configured the SysTick to fire
> c) in the SysTick_Handler, write some other value (lets use
>    0x0022446688aaccee as an example) to one of the D-registers (D0 as
>    an example) and then do "SVC #0"
> d) in the SVC_Handler, write some other value (lets use
>    0x0099aabbccddeeff) to one of the D-registers (D0 as an example)
> 
> In GDB, suspend the execution in the SVC_Handler function and compare
> the value of the D-registers for the SVC_handler frame and the
> SysTick_Handler frame.  With the patch, the value of the modified
> D-register (D0) should be the new value (0x009..eff) on the
> SVC_Handler frame, and the intermediate value (0x002..cee) for the
> SysTick_Handler frame.  Now compare the D-register value for the
> SysTick_Handler frame and the main frame.  The main frame should
> have the initial value (0x112..788).

I suspect pasting a short GDB session here instead of prose may make this
easier to grok.

>  static bool arm_debug;
> +static bool force_fpu_regs_from_stack = false;
>  
>  /* Print an "arm" debug statement.  */
>  
> @@ -3337,6 +3338,17 @@ struct frame_unwind arm_stub_unwind = {
>    arm_stub_unwind_sniffer
>  };
>  
> +
> +/* The first time an exception frame is seen, the lazy stacking of the FPU
> +   registers should be considered.  Any following exception frames should not
> +   consider the lazy stacking as the values will be put on the stack before
> +   branching to the nested exception handler.  */
> +static void
> +reset_force_fpu_regs_from_stack ()
> +{
> +  force_fpu_regs_from_stack = false;
> +}
> +

Is there really no self-contained way to tell that a frame is a "following frame
after lazy stack has been enabled" ?  E.g., can we look at the address in
FPCAR and decide based on it, compared to the current frame address, or something
like that?