ARM Cortex M3 - GNU C Tool chain causes Bus Faults for higher optimisation Levels

Question

I have been trying to execute a GNU C project on ARM Cortex M3 Processor. The project runs happily on -Og optimisation level , but when I tried increasing the optimisation levels to -O2, -O3 , I encountered bus faults.

The GNU tool chain was "arm-none-eabi V10.3.1"

Tried reading the BFSR register and it suggested it was a PRECISERR & STKERR. The fault was happening in a self implemented memset function and was done because the project didn't require the standard CLibs.

void* memset(void s, int c, size_t len){
 unsigned char *dst; 
 dst = (unsigned char) s;
 while (len > 0) {
     *dst = (unsigned char) c;
      dst++; 
      len--;
 } 
return s; } 

Also after going through the Assembly for this function , noticed that this was completely different for the -Og option (which worked) and -O2/3/s option which crashed.

I am copying the screenshot of the assembly for the two options here.

Believe its the return from this function which causes the STKERR, And I have seen a BL instruction (in the -O2/O3/O4 option) which might be the root cause as it pushes the next the instruction address in the Link register and a subsequent pop PC's could fail ?

But I was able to get around the issue by a small modification the code and making the variables as volatile. The new implementation below.

void* memset(void *s, int c, size_t len) {
     unsigned char * volatile dst;
     volatile size_t count = 0;
     dst = (unsigned char * volatile) s;

    while (count <  len) {
        dst[count] = (unsigned char) c;
        count++;
    }
    return s;
}

Please wanted to know whether this is a bug in the GNU tool chain ?

The assembly of the problematic memset function here (-O2/-O3/-Os) :-

    .section    .text.memset,"ax",%progbits
    .align  1
    .p2align 2,,3
    .global memset
    .syntax unified
    .thumb
    .thumb_func
    .type   memset, %function
memset:
    .cfi_startproc
    @ args = 0, pretend = 0, frame = 0
    @ frame_needed = 0, uses_anonymous_args = 0
    push    {r4, lr}
    mov r4, r0
    cbz r2, .L34
    uxtb    r1, r1
    bl  memset
    mov r0, r4
    pop {r4, pc}
    .cfi_endproc

Assembly of the memset function compiled with -Og option (which works)

    .section    .text.memset,"ax",%progbits
    .align  1
    .global memset
    .syntax unified
    .thumb
    .thumb_func
    .type   memset, %function
memset:
    .cfi_startproc
    @ args = 0, pretend = 0, frame = 0
    @ frame_needed = 0, uses_anonymous_args = 0
    @ link register save eliminated.
    mov r3, r0
.L20:
    strb    r1, [r3], #1
    subs    r2, r2, #1
    cmp r2, #0
    bne .L20
    bx  lr
    .cfi_endproc
.LFE81:
    .size   memset, .-memset

Answer 1

Even with -ffreestanding, -nostdlib and similar options, there are certain "library functions" that GCC will nonetheless emit calls to, when it finds that it can optimize code into a call to one of those functions. memset is one of them. So GCC optimizes your memset function into a call to memset, which of course causes infinite recursion and a crash.

This is documented at https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Standards.html#Standards:

Most of the compiler support routines used by GCC are present in libgcc, but there are a few exceptions. GCC requires the freestanding environment provide memcpy, memmove, memset and memcmp. Finally, if __builtin_trap is used, and the target does not implement the trap pattern, then GCC emits a call to abort.

The expectation is that you will implement those functions in assembly language, and that you'd probably want to do so anyway so that you can use hand-optimized versions. As you noticed, you can get away with doing it in C by using tricks like volatile to suppress the optimization, but that's going to result in the most naive and least optimized version of memset and you probably won't be very happy with the performance.

Getting GCC to compile without inserting call to memcpy also suggests using -fno-tree-loop-distribute-patterns. Combined with -O3 it uses 16-byte SIMD stores instead of single-byte strb, so that's a considerable improvement. https://godbolt.org/z/K8645on1e. Some future compiler version may break this, however.

Answer 2

So we basically answered this yesterday in comments. And then Nate answered it with how to get around it. That or just do not use -O3 use -O2 (at least on the gnu I was using). In general do not use -O3.

typedef __SIZE_TYPE__ size_t;
void* memset(void *s, int c, size_t len)
{
 unsigned char *dst; 
 dst = (unsigned char *)s;
 while (len > 0) {
     *dst = (unsigned char) c;
      dst++; 
      len--;
 } 
 return s; 
} 



00000000 <memset>:
   0:   b510        push    {r4, lr}
   2:   4604        mov r4, r0
   4:   b112        cbz r2, c <memset+0xc>
   6:   b2c9        uxtb    r1, r1
   8:   f7ff fffe   bl  0 <memset>
   c:   4620        mov r0, r4
   e:   bd10        pop {r4, pc}



typedef __SIZE_TYPE__ size_t;
void* fun(void *s, int c, size_t len)
{
 unsigned char *dst; 
 dst = (unsigned char *)s;
 while (len > 0) {
     *dst = (unsigned char) c;
      dst++; 
      len--;
 } 
 return s; 
} 


00000000 <fun>:
   0:   b510        push    {r4, lr}
   2:   4604        mov r4, r0
   4:   b112        cbz r2, c <fun+0xc>
   6:   b2c9        uxtb    r1, r1
   8:   f7ff fffe   bl  0 <memset>
   c:   4620        mov r0, r4
   e:   bd10        pop {r4, pc}