Chibios 3.0.0 gcc support

[Badger]

I'm trying to build demos using the latest Chibios trunk but am experiencing compiler problems:

Code: Select all

[~/projects/chibios/demos/STM32/RT-STM32F407-DISCOVERY]$ make
Compiler Options
arm-none-eabi-gcc -c -mcpu=cortex-m4 -O2 -ggdb -fomit-frame-pointer -falign-functions=16 -ffunction-sections -fdata-sections -fno-common -flto -Wall -Wextra -Wstrict-prototypes -Wa,-alms=build/lst/ -DCORTEX_USE_FPU=FALSE -DTHUMB_PRESENT -mno-thumb-interwork -DTHUMB_NO_INTERWORKING -MD -MP -MF .dep/build.d -I. -I../../../os/ext/CMSIS/include -I../../../os/ext/CMSIS/ST -I../../../os/common/ports/ARMCMx/devices/STM32F4xx -I../../../os/rt/ports/ARMCMx -I../../../os/rt/ports/ARMCMx/compilers/GCC -I../../../os/rt/include -I../../../test/rt -I../../../os/hal/include -I../../../os/hal/osal/rt -I../../../os/hal/ports/common/ARMCMx -I../../../os/hal/ports/STM32/STM32F4xx -I../../../os/hal/ports/STM32/LLD -I../../../os/hal/ports/STM32/LLD/DACv1 -I../../../os/hal/ports/STM32/LLD/GPIOv2 -I../../../os/hal/ports/STM32/LLD/I2Cv1 -I../../../os/hal/ports/STM32/LLD/OTGv1 -I../../../os/hal/ports/STM32/LLD/RTCv2 -I../../../os/hal/ports/STM32/LLD/SPIv1 -I../../../os/hal/ports/STM32/LLD/TIMv1 -I../../../os/hal/ports/STM32/LLD/USARTv1 -I../../../os/hal/boards/ST_STM32F4_DISCOVERY -I../../../os/various main.c -o main.o

mkdir -p build/obj
mkdir -p build/lst
Compiling chcoreasm_v7m.s
Compiling crt0.c
Compiling vectors.c
Compiling chcore.c
Compiling chcore_v7m.c
Compiling chsys.c
Compiling chdebug.c
Compiling chtm.c
Compiling chstats.c
Compiling chschd.c
Compiling chvt.c
Compiling chthreads.c
Compiling chdynamic.c
Compiling chregistry.c
Compiling chsem.c
Compiling chmtx.c
Compiling chcond.c
Compiling chevents.c
Compiling chmsg.c
Compiling chmboxes.c
Compiling chqueues.c
Compiling chmemcore.c
Compiling chheap.c
Compiling chmempools.c
Compiling test.c
Compiling testthd.c
Compiling testsem.c
Compiling testmtx.c
Compiling testmsg.c
Compiling testmbox.c
Compiling testevt.c
Compiling testheap.c
Compiling testpools.c
Compiling testdyn.c
Compiling testqueues.c
Compiling testbmk.c
Compiling hal.c
Compiling hal_queues.c
Compiling hal_mmcsd.c
Compiling adc.c
Compiling can.c
Compiling dac.c
Compiling ext.c
Compiling gpt.c
Compiling i2c.c
Compiling i2s.c
Compiling icu.c
Compiling mmc_spi.c
Compiling pal.c
Compiling pwm.c
Compiling sdc.c
Compiling serial.c
Compiling serial_usb.c
Compiling spi.c
Compiling st.c
Compiling uart.c
Compiling usb.c
Compiling osal.c
Compiling nvic.c
Compiling stm32_dma.c
Compiling hal_lld.c
Compiling adc_lld.c
Compiling ext_lld_isr.c
Compiling can_lld.c
Compiling ext_lld.c
Compiling mac_lld.c
Compiling sdc_lld.c
Compiling dac_lld.c
Compiling pal_lld.c
Compiling i2c_lld.c
Compiling usb_lld.c
Compiling rtc_lld.c
Compiling i2s_lld.c
Compiling spi_lld.c
Compiling gpt_lld.c
Compiling icu_lld.c
Compiling pwm_lld.c
Compiling st_lld.c
Compiling serial_lld.c
Compiling uart_lld.c
Compiling board.c
Compiling main.c
main.c: In function 'Thread1':
main.c:36:1: warning: no return statement in function returning non-void [-Wreturn-type]
 }
 ^
Linking build/ch.elf
main.c: In function 'main':
main.c:41:5: internal compiler error: Segmentation fault: 11
 int main(void) {
     ^
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
lto-wrapper: arm-none-eabi-gcc returned 1 exit status
/Users/tom/dev/arm/gcc/gcc-arm-none-eabi-4_8-2013q4/bin/../lib/gcc/arm-none-eabi/4.8.3/../../../../arm-none-eabi/bin/ld: lto-wrapper failed
collect2: error: ld returned 1 exit status
make: *** [build/ch.elf] Error 1
[~/projects/chibios/demos/STM32/RT-STM32F407-DISCOVERY]$ svn info
Path: .
Working Copy Root Path: /Users/tom/projects/chibios
URL: http://svn.code.sf.net/p/chibios/svn/trunk/demos/STM32/RT-STM32F407-DISCOVERY
Repository Root: http://svn.code.sf.net/p/chibios/svn
Repository UUID: 35acf78f-673a-0410-8e92-d51de3d6d3f4
Revision: 6922
Node Kind: directory
Schedule: normal
Last Changed Author: gdisirio
Last Changed Rev: 6917
Last Changed Date: 2014-05-07 10:24:47 +0100 (Wed, 07 May 2014)

I've tried a few different gcc arm builds but all result in the same. Is there a particular gcc version that I should be using?

[Giovanni]

The latest 4.7 from here works for me: https://launchpad.net/gcc-arm-embedded

You could give a try also to the bleeding edge toolchain: http://www.freddiechopin.info/en/downlo ... -toolchain

Are you using Win8? it could be related to that.

Giovanni

[saraben]

Badger,
Have a look at http://forum.chibios.org/phpbb/viewtopic.php?f=16&t=1867
There is a bug in gcc-arm-none-eabi-4_8. It can be used with LTO disabled.
I have noticed that code compiled withgcc-arm-none-eabi-4_8-2014q1 and LTO turned off is almost as small as gcc-arm-none-eabi-4_7-2013q3 with LTO turned on.

Regards
saraben

[Giovanni]

I tried the bleeding edge toolchain 4.8.3 and it work with LTO apparently. It is also faster than the other compiler from launchpad.

Giovanni

[Badger]

Thanks for the help everyone, disabling LTO allowed it to build

Code: Select all

# Enable this if you want link time optimizations (LTO)
ifeq ($(USE_LTO),)
  USE_LTO = no
endif

[saraben]

I tried the bleeding edge toolchain 4.8.3 and it work with LTO apparently. It is also faster than the other compiler from launchpad.

Giovanni

That's interesting I just tried gcc-arm-none-eabi-4_8-140405 (Bleading Edge) on Ubuntu (using OS kernel 3.5.0-49-generic) and it behaves the same as gcc-arm-none-eabi-4_8-2014q1.
The build date of the BE version is a couple of days before the Launchpad version and the info file says 4.8.2 built on kernel "build system: Linux 3.13.8-1-ARCH", where as the website http://www.freddiechopin.info/en/download/category/11-bleeding-edge-toolchain indicates 4.8.3.

So it looks like it is still turn off LTO or stick with 4.7 on Linux at least.
Giovanni, you are still on Windows?
Perhaps there is a host compiler or OS difference? I really should upgrade, my OS, 3.5, is getting a bit old but I don't like upgrading just after a Ubuntu release. I perefer to give it a couple of months.
Regards
saraben

[Giovanni]

Windows XP, it works apparently. It is strange to have such a compiler failure on Linux, probably it would be a good idea to ask on the GCC mailing list or search in the bug tracker.

Giovanni

[saraben]

Giovanni,
I had a bit more of a look at this and found that for one modified version of the F103 demo I could compile with gcc-arm-none-eabi-4_8-2014q1 and LTO enabled and another failed. The difference was that the failing version included the TestThread. Placing the TestThread back in the compiling modified version made it fail also.

I don't believe it is anything to do with the TestThread.

Looking at https://bugs.launchpad.net/gcc-arm-embedded/+bug/1289281 it looks like 4.8 may never be reliable with LTO.

I also verified what alex31 stated in the other thread that removing the -ggdb (not -gddb) switch also appears to solve the problem. Not much good for development though

It is most likely that there is a code size issue as suggested in the above bug report.

Regards
saraben.

[Giovanni]

This is bad, I recommend staying with 4.7.x until 4.9.x with the fix becomes available.

Giovanni

[alex31]

reading the above link on the launchpad bug report, it seems that the bug is due to the multithreaded nature of final link.
another workaround for this bug is to enforce mono thread linking using this option :

Code: Select all

-flto-partition=1to1

tested with last bleeding egde compiler (linux 64 bits) : it compiles now all the demos.
i have tested linking time with and without -flto-partition=1to1, and using this option only make
linking 10% slower on my 4 cpus 8 threads box

Alexandre