link time optimization
Posted: Wed Nov 28, 2012 11:13 pm
I tried building my program with gcc 4.7.3 and enabling -flto in the compile and link steps. I'm mostly doing this because I'm curious if there would actually be any benefit. I'm getting the following error:
From what I can tell, this is caused by the fact that the symbol __main_stack_end__ is extern declared with two different types. In crt0.c it is:
while in the various vectors.c it is:
So in one case it is a uint32_t and in the other case it is a function pointer. Later in crt0.c, a the fill32 used is used on __main_stack_end__ and maybe a simple cast here would do the trick, rather than redeclaring the type of __main_stack_end__ to be a uint32_t.
If there is a simple work around for this, I'd be interested to try it out and report back.
Thanks,
Luke
Code: Select all
In file included from :2:0:
/home/hazelnusse/repos/ChibiOS/os/ports/GCC/ARMCMx/crt0.c:126:17: error: function '__main_stack_end__' redeclared as variable
In file included from /home/hazelnusse/repos/ChibiOS/os/ports/common/ARMCMx/nvic.h:151:0,
from :3:
/home/hazelnusse/repos/ChibiOS/os/ports/GCC/ARMCMx/STM32F4xx/vectors.c:34:13: note: previously declared here
lto1: fatal error: errors during merging of translation units
compilation terminated.
lto-wrapper: /home/hazelnusse/toolchain/bin/arm-none-eabi-g++ returned 1 exit status
/home/hazelnusse/toolchain/lib/gcc/arm-none-eabi/4.7.3/../../../../arm-none-eabi/bin/ld: lto-wrapper failed
collect2: error: ld returned 1 exit status
make: *** [build/robot.bike.elf] Error 1
From what I can tell, this is caused by the fact that the symbol __main_stack_end__ is extern declared with two different types. In crt0.c it is:
Code: Select all
extern uint32_t __main_stack_end__;
while in the various vectors.c it is:
Code: Select all
extern void __main_stack_end__(void);
So in one case it is a uint32_t and in the other case it is a function pointer. Later in crt0.c, a the fill32 used is used on __main_stack_end__ and maybe a simple cast here would do the trick, rather than redeclaring the type of __main_stack_end__ to be a uint32_t.
If there is a simple work around for this, I'd be interested to try it out and report back.
Thanks,
Luke