Re: [PATCH] libc: arm: setjmp jmp_buf exagerated size

[Bernhard Krug <b.krug@elektronenpumpe.de>]

On February 15, 2023 5:12:04 PM GMT+01:00, Richard Earnshaw <Richard.Earnshaw@foss.arm.com> wrote:
>
>
>On 15/02/2023 11:09, Bernhard Krug wrote:
>> Patch sets correct jmp_buf size for armv6-m conforming to implementation in setjmp.S
>> 
>> FYI a table of cortex architectures:
>> __ARM_ARCH_6M__ cortex-m0/m0+/m1 no fpu option
>> __ARM_ARCH_7M__ cortex-m3 no fpu option
>> __ARM_ARCH_7EM__ cortex-m4 optional fpu
>> check using __ARM_FP
>
>I don't think it's as simple as this.  The ABI supports three variants, two of which are call compatible.
>
>hard-float (where you must have hardware FP)
>soft (where you haven't got any hardware FP)
>softfp (where you have hardware FP but need to inter-operate with code that doesnt).
>
>soft and softfp are call compatible and so any jump-bufs created need to support saving and restoring the FP context.
>
>I guess a configure-time option to disable support for softfp might be an option, but the default needs to ensure things are compatible.
>
>R.

As far as I understand the source in setjmp.S in the case of armv6-m it is.
Looking in the source 
https://github.com/bminor/newlib/blob/master/newlib/libc/machine/arm/setjmp.S#L89
How I read this: It will never copy more than ten registers because of the exclusive #if #else ...

But okay let it be 20 registers.
Then does it have to be "long long" only for special chips that use wider registers in their FPU?

Then I'll hope for a decision-tree ARM_ARCH_xy ARM_FP ARM_NEON in the future :)