Fails to link on arm-none-eabi-gcc 8.2.0 with -flto (CM4F)
Hi, we have recently tried to update our compiler at work but we are having some difficulties with getting the project to link. It appears that the ldr:s in source/portable/GCC/ARM_CM4F/port.c
~~~
static void prvPortStartFirstTask( void )
{
__asm volatile(
” ldr r0, =0xE000ED08 n” /* Use the NVIC offset register to locate the stack. /
” ldr r0, [r0] n”
” ldr r0, [r0] n”
” msr msp, r0 n” / Set the msp back to the start of the stack. /
” cpsie i n” / Globally enable interrupts. /
” cpsie f n”
” dsb n”
” isb n”
” svc 0 n” / System call to start first task. */
” nop n”);
}
and
static void vPortEnableVFP( void )
{
__asm volatile (
” ldr.w r0, =0xE000ED88 n” /* The FPU enable bits are in the CPACR. /
” ldr r1, [r0] n”
” n”
” orr r1, r1, #( 0xf << 20 ) n” / Enable CP10 and CP11 coprocessors, then save back. */
” str r1, [r0] n”
” bx r14 “);
}
~~~
Gets a too long PC relative offset when building with -flto. For some reason the literal pool ends up too far away from the instruction. I propose that .ltorg directives are placed at the end of each function in order to explicitly declare the literal pool straight after the epilogue:
~~~
static void prvPortStartFirstTask( void )
{
__asm volatile(
” ldr r0, =0xE000ED08 n” /* Use the NVIC offset register to locate the stack. /
” ldr r0, [r0] n”
” ldr r0, [r0] n”
” msr msp, r0 n” / Set the msp back to the start of the stack. /
” cpsie i n” / Globally enable interrupts. /
” cpsie f n”
” dsb n”
” isb n”
” svc 0 n” / System call to start first task. /
” nop n”
” .ltorg n”); / Ensure a literal pool for the first ldr in range when using lto */
}
static void vPortEnableVFP( void )
{
__asm volatile (
” ldr.w r0, =0xE000ED88 n” /* The FPU enable bits are in the CPACR. /
” ldr r1, [r0] n”
” n”
” orr r1, r1, #( 0xf << 20 ) n” / Enable CP10 and CP11 coprocessors, then save back. /
” str r1, [r0] n”
” bx r14 n”
” .ltorg “); / Ensure a literal pool for the first ldr in range when using lto */
}
~~~
With these changes, the project links and when looking at the generated machine code the PC relative load is within ~20 bytes.
Kind regrads,
Philip
Fails to link on arm-none-eabi-gcc 8.2.0 with -flto (CM4F)
Thanks for your post. We are aware of issues with link time and whole
program optimisation but somewhat reluctant to make edits that are
difficult for us to test in all scenarios, and without knowing the
impact on existing users [who are not using those optimizations].