libc: arm: setjmp jmp_buf exagerated size

libc: arm: setjmp jmp_buf exagerated size

[Bernhard Krug]

Hello, 

using setjmp to implement eight coroutines on an ARM Cortex-M0+ the allocated size of .data escalates, in my example, from 476 bytes to 1444 bytes!

I think "libc: arm: fix setjmp abi non-conformance" shouldn't use jmp_buf made of 20 long long ints on a 32bit arm without fpu :D

Can the #ifndef device detection/decision tree from the setjmp asm/source file be also used in the headers to set reasonable sizes?

For my machine and use-case gcc emits asm copying ten registers (as expected) which would be rightly sized.

Thanks for your work and consideration :)

[PATCH] libc: arm: setjmp jmp_buf exagerated size

[Bernhard Krug]

[-- Attachment #1: Type: text/plain, Size: 276 bytes --]

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

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: setjmp.patch --]
[-- Type: text/x-diff; name=setjmp.patch, Size: 411 bytes --]

--- /usr/arm-none-eabi/include/machine/setjmp.h	2023-02-13 17:06:37.000000000 +0100
+++ setjmp.h	2023-02-15 11:47:15.668073267 +0100
@@ -9,7 +9,9 @@
 #define _JBTYPE unsigned long
 #endif
 
-#if defined(__arm__) || defined(__thumb__)
+#ifdef __ARM_ARCH_6M__
+#define _JBLEN 10 /* r4 - r10, fp, sp, lr */
+#elif defined(__arm__) || defined(__thumb__)
 /*
  * All callee preserved registers:
  *  core registers:

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

[Bernhard Krug]

set correct jmp_buf size for ARMv6-M conforming to implementation in setjmp.S
---
diff --git a/newlib/libc/include/machine/setjmp.h b/newlib/libc/include/machine/setjmp.h index 29b76ce..cdd0a6a 100644 --- a/newlib/libc/include/machine/setjmp.h +++ b/newlib/libc/include/machine/setjmp.h @@ -9,7 +9,9 @@ _BEGIN_STD_C #define _JBTYPE unsigned long #endif -#if defined(__arm__) || defined(__thumb__) +#ifdef __ARM_ARCH_6M__ +#define _JBLEN 10 /* r4 - r10, fp, sp, lr */ +#elif defined(__arm__) || defined(__thumb__) /* * All callee preserved registers: * core registers:

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

[Bernhard Krug]

set correct jmp_buf size for ARMv6-M conforming to implementation in setjmp.S
---
diff --git a/newlib/libc/include/machine/setjmp.h b/newlib/libc/include/machine/setjmp.h
index 29b76ce..cdd0a6a 100644
--- a/newlib/libc/include/machine/setjmp.h
+++ b/newlib/libc/include/machine/setjmp.h
@@ -9,7 +9,9 @@ _BEGIN_STD_C
#define _JBTYPE unsigned long
#endif
-#if defined(__arm__) || defined(__thumb__)
+#ifdef __ARM_ARCH_6M__
+#define _JBLEN 10 /* r4 - r10, fp, sp, lr */
+#elif defined(__arm__) || defined(__thumb__)
/* * All callee preserved registers:
* core registers:

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

[Richard Earnshaw]

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.

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

[Bernhard Krug]

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 :)

Re: [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.

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

[Bernhard Krug]

On February 15, 2023 6:01:05 PM GMT+01:00, Richard Earnshaw <Richard.Earnshaw@foss.arm.com> wrote:
>
>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.
>
You are right. I didn't consider this in my MCU project yet :D
Thank you.