Crash when cross compiling for ARM with GCC-8-2-0 and -ftree-loop-distribute-patterns

[Richard Earnshaw (lists)]

On 17/10/2019 15:04, Josef Wolf wrote:
> Tahnks for your help, Matthias!
> 
> On Thu, Oct 17, 2019 at 02:37:11PM +0200, Matthias Pfaller wrote:
> 
>> Have a look at "arm-eabi-objdump -S -d main.elf". Sometimes this is
>> quite revealing.
> 
> Yeah.
> 
>> Are you using openocd or something similar for debugging?
> 
> Yes. Openocd with gdb.
> 
>> You are compiling for a cortex-m0/3/4?
> 
> Cortex-m3
> 
>> Are you single stepping through the complete startup sequence or do set a
>> break point ath the top of memset (i.e. are break points working at all)?
> 
> Breakpoints are working. But there is only a limited set of hardware
> breakpoints (four, AFAIR).
> 
>> Interrupts are still disabled?
> 
> There are no interrupt sources enabled yet. But I wonder why the CPU is not
> starting up with disabled IRQs? I am new to the ARM architecture, but every
> other architecture I know of would come out from reset with disabled
> interrupts... I'd expect BASEPRI and PRIMASK to be set to sane values before
> the first instruction is executed?
> 
> Anyway, explicitly calling __set_PRIMASK(1) did also not help, although
> primask ist still set when the processor crashes.
> 
>> Why is the stack pointer so low at this point of execution? Using
>> 0x20018000-0x20017d20 == 0x2e0 bytes of stack seems a little excessive
>> for just one call.
> 
> Ah!... Looks like you've spotted the problem! Actually, the SP is decremented
> on every cycle of the loop:
> 
>    (gdb) disass
>    Dump of assembler code for function memset:
>       0x08001008 <+0>:    push {r4, lr}
>       0x0800100a <+2>:    mov  r4, r0
>       0x0800100c <+4>:    cbz  r2, 0x8001014 <memset+12>
>    => 0x0800100e <+6>:    uxtb r1, r1
>       0x08001010 <+8>:    bl   0x8001008 <memset>
>       0x08001014 <+12>:   mov  r0, r4
>       0x08001016 <+14>:   pop  {r4, pc}
>    End of assembler dump.
> 
> This looks REALLY suspicous to me. Every cycle of the loop in memset() is
> pushing something onto the stack?!?
> 
> Without the  -ftree-loop-distribute-patterns option, the memset() function
> looks entirely different:
> 
>           cbz    r2, <memset+18>
>           add    r2, r0
>           subs   r2, #1
>           uxtb   r1, r1
>           subs   r3, r0, #1
>    <+10>: strb.w r1, [r3, #1]!
>           cmp    r3, r2
>           bne.n  <memset+10>
>    <+18>: bx     lr
> 
>> I usually start toggling output lines when I'm stuck like this...
> 
> ?
> 
> 

The compiler has spotted that you've written something that acts like 
memset and optimized it into a function call to memset.  So now you're 
recursing to oblivion.  Try adding -fno-builtin-memset to your compile 
options.

R.