Menu
▾
▴
#465 Wrong multilib handling in ChibiOS buildsystem
It seems there is quite problematic bug in multilib handling in ChibiOS makefiles. It takes me a little time to find a reason why the application (for STM32F4) crashes randomly inside libm.a from toolchain when compiled in hardfp and works in soft and softfp.
Build system need to pass all flags used by compiler to chose correct multilib for target in this case not only -mcpu=xxx but also flags for FPU usage like -mfpu=xxx -mfloat-abi=xxx
In most cases (soft or softfp) this is harmles, but my current project is used to check the performance for some components in various envinroments and this cause a funny problems.
Quick example:
- Compiled with USE_FPU=no
In this case it's perfectly OK. Acording to map file:
.../bin/../lib/gcc/arm-none-eabi/4.8.3/../../../../arm-none-eabi/lib/armv7e-m/libm.a(lib_a-s_ceil.o)
- Compiled with USE_FPU=yes
Wrong multilib directory used (should use libm.a from softfp). Acording to map file:
.../bin/../lib/gcc/arm-none-eabi/4.8.3/../../../../arm-none-eabi/lib/armv7e-m/libm.a(lib_a-s_ceil.o)
- Compiled with USE_FPU=yes and hardfp
This case gives me problem as it still use libm.a from common directory, but it should use fpu subdirectory.
This problem not only hit's in libm.a, but all libs from gcc toolchain (libc.a, libstdc++.a, etc)
Summary: Buildsystem should append -mfpu=xxx -mfloat-abi=xxx flags not only to compile but also for linking target. This solved mysterious crashes for me.
I propose introduce a new variable (as MCFLAGS but for FPU related options) for example FPFLAGS= and use it in rules.mk for targets that supports FPU by adding it to MCFLAGS (as they are used in LDFLAGS) as:
MCFLAGS = -mcpu=$(MCU) $(FPFLAGS)
or directly to LDFLAGS:
LDFLAGS = $(MCFLAGS) $(FPFLAGS) -nostartfiles -T$(LDSCRIPT) ...
A little dirty, but should solve users looking for mysterious bugs in case of FPU usage.
Hi,
Please verify the new makefile system in the 3.0 branch, this issue should already be resolved there. I am thinking to backport that to the 2.6 branch.
Yes. The solution from 3.x branch is perfect and solved problem. It would be great to see this feature ported to 2.6.x as my current project is related to work not home use and if I understand it correctly I can use only unmodified 2.6 version.
This is a complex change and I don't want to implement it in both 2.6.x and trunk. I will implement it in 2.6.x only after 2.7 will be replaced by 3.0 as trunk.
In the meanwhile feel free to use the 3.0 makefiles, those are not covered by the GPL and thus are not impacted by the exception text too.
I wonder do you have any planns to release 2.7 anytime soon ? I would like to use ADC and I2S in project and this would save me a lot of work ?
Anyway I modified Makefile a little to have the same effect without porting the build system. See attached patch ... crude, but works fine enough until release of 3.x
I see you backported the make system and it works quite nice. One small problem it breaks the compilation without LINK_GC and with USE_LDOPT empty.
At the link stage: /home/morgoth/Development/ARM32/bin/../lib/gcc/arm-none-eabi/4.8.3/../../../../arm-none-eabi/bin/ld: cannot find : Not such file or directory
Looking at ld arguments I see something like that:
-Wl,-Map=build/slsSB.map,--cref,--no-warn-mismatch,--library-path=/home/morgoth/Development/ProjectsFIMS/stm32-sls/sb/../vendor/chibios/os/ports/GCC/ARMCMx,--script=/home/morgoth/Development/ProjectsFIMS/stm32-sls/sb/bootloader/ld/STM32F103xD.ld,,--defsym=process_stack_size=0x400,--defsym=main_stack_size=0x400
Notice the double ,, argument ? It seems the ordering in rules.mk is wrong. Take a look at attached path which fixed problem for me.
OK it seems it's a little more complex ;) I guess it would be quite hard to fix it more clean way as -Wl needs comma as separator. Attached another proposed patch.
I committed a fix, hopefully it is right this time.
Will be fixed in 2.6.4stable.