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

[Pedro Alves <pedro@palves.net>]

On 2022-09-30 4:26 p.m., Torbjorn SVENSSON wrote:
> Hi,
> 
> On 2022-09-30 17:13, Pedro Alves wrote:

>> 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?
> 

It does to me.

I suppose the scheme could break if it's possible to have something
like sigaltstack, or coroutines, i.e., some frames after lazy FPU has been enabled are
actually running with a different stack.  Not sure, maybe you'd never see lazy FPU
stacking be enabled across the cpu/thread switching stacks?

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

Thanks.