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

[Torbjorn SVENSSON <torbjorn.svensson@foss.st.com>]

Hi,

On 2022-09-30 17:13, Pedro Alves wrote:
> 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?

As the function is Cortex-M specific, I suppose it would be fine to 
assume that the stack always grows downwards. With this assumption, I 
suppose we could compare the value in FPCAR with the value of $sp of the 
frame to be unwinded after the current frame.
- If the value is lower, then I think it's safe to assume that the 
stacked content should be used.
- If the value is greater, then I think it's safe to assume that it's up 
to LSPACT, LSPEN and ASPEN to define if it's going to be register or 
stacked content that should be used.

Does this sound reasonable?

I'll try to find some time later today or in the weekend to give it a try.

Kind regards,
Torbjörn