[PATCH] libc: arm: setjmp jmp_buf exagerated size

[Richard Earnshaw]

On 15/02/2023 16:40, Bernhard Krug wrote:
> 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 you can build your source file with a jmp_buf in it, and if you then 
end up linking it against a version of the library that expects a larger 
buffer it will end up corrupting data.

The following has to work

file1.c // compiled for arm6m soft-float
file2.c // compiled for arm7m softfp

image  // link file1.o and file2.o with softfp libraries.

This can't lead to file1 having a different jmp_buf size or layout to 
file2 or the version in the library.
> 
> 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?

long long is used for alignment, but that doesn't affect the size 
because you only need half the number of long longs as you do longs.

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

R.