ARM compilation error, VFP registers used by executable, not object file
GccCompilationArmGcc Problem Overview
I have been having this problem for the last few days and I can't get my head around what is really happening here, or what is the problem.
I have a makefile with these flags:
CC = arm-linux-gnueabihf-gcc-4.6
FLAGS = -O3 -march=armv7-a -mtune=cortex-a9 -mfpu=neon -ftree-vectorize -mfloat-abi=softfp -std=gnu99
I have a library in a .a file, which has some object files, all I need to do is link them in with my executable. I know the prototypes and all that, the only thing that complains is the following:
/usr/bin/ld: error: *EXECUTABLE* uses VFP register arguments, *OBJECTFILE* does not
/usr/bin/ld: failed to merge target specific data of file *OBJECTFILE*
When I don't use the -mfloat-abi=softfp, I get another error relating to floating point registers.
Does anyone have any idea what is causing this, and what I can do to fix this, such as making it so that my executable does not use Virtual Floating Point Register arguments?
x@x:~/Desktop/perf_test$ make
arm-linux-gnueabihf-gcc-4.6 -c -O3 -march=armv7-a -mtune=cortex-a9 -mfpu=neon -ftree-vectorize -std=gnu99 -mfloat-abi=softfp perf_test.c ../baseline/util.c
arm-linux-gnueabihf-gcc-4.6 -o perf_test perf_test.o util.o ../baseline/lib.a
/usr/bin/ld: error: perf_test uses VFP register arguments, perf_test.o does not
/usr/bin/ld: failed to merge target specific data of file perf_test.o
/usr/bin/ld: error: perf_test uses VFP register arguments, util.o does not
/usr/bin/ld: failed to merge target specific data of file util.o
/usr/bin/ld: error: perf_test uses VFP register arguments, ../baseline/lib.a(a.o) does not
/usr/bin/ld: failed to merge target specific data of file ../baseline/lib.a(a.o)
/usr/bin/ld: error: perf_test uses VFP register arguments, ../baseline/lib.a(b.o) does not
/usr/bin/ld: failed to merge target specific data of file ../baseline/lib.a(b.o)
/usr/bin/ld: error: perf_test uses VFP register arguments, ../baseline/lib.a(c.o) does not
/usr/bin/ld: failed to merge target specific data of file ../baseline/lib.a(c.o)
/usr/bin/ld: error: perf_test uses VFP register arguments, ../baseline/lib.a(d.o) does not
/usr/bin/ld: failed to merge target specific data of file ../baseline/lib.a(d.o)
/usr/bin/ld: error: perf_test uses VFP register arguments, ../baseline/lib.a(e.o) does not
/usr/bin/ld: failed to merge target specific data of file ../baseline/lib.a(e.o)
/usr/bin/ld: error: perf_test uses VFP register arguments, ../baseline/lib.a(f.o) does not
/usr/bin/ld: failed to merge target specific data of file ../baseline/lib.a(f.o)
collect2: ld returned 1 exit status
make: *** [perf_test] Error 1
Gcc Solutions
Solution 1 - Gcc
Your target triplet indicates that your compiler is configured for the hard-float ABI. This means that the libgcc library will also be hardfp. The error message indicates that at least part of your system is using soft-float ABI.
If the compiler has multilib enabled (you can tell with -print-multi-lib) then you can use -mfloat-abi=softfp, but if not then that option won't help you much: gcc will happily generate softfp code, but then there'll be no compatible libgcc to link against.
Basically, hardfp and softfp are just not compatible. You need to get your whole system configured one way or the other.
EDIT: some distros are, or will be, "multiarch". If you have one of those then it's possible to install both ABIs at once, but that's done by doubling everything up -- the compatibility issues still exist.
Solution 2 - Gcc
I have found on an arm hardfloat system where glibc binutils and gcc were crosscompiled, using gcc gives the same error.
It is solved by exporting-mfloat-abi=hard to flags, then gcc compiles without errors.
Solution 3 - Gcc
Also the error can be solved by adding several flags, like -marm -mthumb-interwork. It was helpful for me to avoid this same error.
Solution 4 - Gcc
This is guesswork, but you may need to supply some or all of the floating point related switches for the link stage as well.
Solution 5 - Gcc
I encountered the issue using Atollic for ARM on STM32F4 (I guess it applies to all STM32 with FPU).
Using SW floating point didn't worked well for me (thus compiling correctly).
When STM32cubeMX generates code for TrueStudio (Atollic), it doesn't set an FPU unit in C/C++ build settings (not sure about generated code for other IDEs).
Set a FPU in "Target" for (under project Properties build settings):
- Assembler
- C Compiler
- C Linker
Then you have the choice to Mix HW/SW fp or use HW.
Generated command lines are added with this for the intended target:
-mfloat-abi=hard -mfpu=fpv4-sp-d16
[tag:arm][tag:Atollic]
Solution 6 - Gcc
Use the same compiler options for linking also.
Example:
gcc -mfloat-abi=hard fpu=neon -c -o test.cpp test.o
gcc -mfloat-abi=hard fpu=neon -c test1.cpp test1.o
gcc test.o test1.o mfloat-abi=hard fpu=neon HardTest
Solution 7 - Gcc
In my case CFLAGS = -O0 -g -Wall -I. -mcpu=cortex-m4 -mthumb -mfpu=fpv4-sp-d16 -mfloat-abi=soft has helped. As you can see, i used it for my stm32f407.
Solution 8 - Gcc
I was facing the same issue. I was trying to build linux application for Cyclone V FPGA-SoC. I faced the problem as below:
Error: <application_name> uses VFP register arguments, main.o does notI was using the toolchain
arm-linux-gnueabihf-g++ provided by embedded software design tool of altera.
It is solved by exporting:
mfloat-abi=hard to flags, then arm-linux-gnueabihf-g++ compiles without errors. Also include the flags in both CC & LD.
Solution 9 - Gcc
In my particular case -g -march=armv7-a -mfloat-abi=hard -mfpu=neon -marm -mthumb-interwork worked.
Solution 10 - Gcc
This answer may appear at the surface to be unrelated, but there is an indirect cause of this error message.
First, the "Uses VFP register..." error message is directly caused from mixing mfloat-abi=soft and mfloat-abi=hard options within your build. This setting must be consistent for all objects that are to be linked. This fact is well covered in the other answers to this question.
The indirect cause of this error may be due to the Eclipse editor getting confused by a self-inflicted error in the project's ".cproject" file. The Eclipse editor frequently reswizzles file links and sometimes it breaks itself when you make changes to your directory structures or file locations. This can also affect the path settings to your gcc compiler - and only for a subset of your project's files. While I'm not yet sure of exactly what causes this failure, replacing the .cproject file with a backup copy corrected this problem for me. In my case I noticed .java.null.pointer errors after adding an include directory path and started receiving the "VFP register error" messages out of the blue. In the build log I noticed that a different path to the gcc compiler was being used for some of my sources that were local to the workspace, but not all of them!? The two gcc compilers were using different float settings for unknown reasons - hence the VFP register error.
I compared the .cproject settings with a older copy and observed differences in entries for the sources causing the trouble - even though the overriding of project settings was disabled. By replacing the .cproject file with the old version the problem went away, and I'm leaving this answer as a reminder of what happened.
Solution 11 - Gcc
"Note that the hard-float and soft-float ABIs are not link-compatible; you must compile your entire program with the same ABI, and link with a compatible set of libraries." https://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html arm-none-eabi-gcc.exe
Silicon Labs "kjostera" "Employee" response to EFR32 Flex Gecko (crossreference Cortex-M4F): "So code compiled with the softfp ABI is not link time compatible with code compiled with hardfp ABI. So since we currently only support RAIL library compiled using the softfp ABI, this means that you will have to build your application as well using the softfp ABI."
"Note that using softfp ABI does not mean that your code cannot use FPU instructions. Any code doing floating point arithmetic will use the FPU when the compiler thinks that it makes sense."
"kjostera" then goes on to demonstrate that the GCC 7 generated Assembly for both the case of -mfloat-abi=softfp and -mfloat-abi=hard, the vmul.f32 instruction is invoked and the instruction count is 10 for softfp and 9 for hard.
<https://www.silabs.com/community/mcu/32-bit/forum.topic.html/enable_fpu_in_rail-p-SEYr> <https://www.silabs.com/documents/public/data-sheets/efr32fg1-datasheet.pdf> <https://www.silabs.com/documents/public/reference-manuals/efr32xg12-rm.pdf> <https://www.silabs.com/documents/public/reference-manuals/efr32xg13-rm.pdf> <https://www.silabs.com/documents/public/reference-manuals/efr32xg14-rm.pdf>
Solution 12 - Gcc
Another reason for this problem is that you omitted the cpu architecture specification of the final binary target.
For example, even if your -mfloat-abi and -mfpu switches agree between all modules and the final binary, you can still get tripped up on -mcpu.
In my case, omitting -mcpu=cortex-m4 for the final binary caused the linker to default to some other cpu architecture. This also produced the same message about VFP registers.
Solution 13 - Gcc
I had similar problem by statical linking my project with some external library for Raspberry. Any from mentioned compiler options could help. By comparison of readelf output of mine object files and object files of the static library i was linking, i came over to use another Cross-Compiler. With the same compiler options I used as before, the problem was not seen any more. So, perhaps you just need to use the right Cross-Compiler, supporting the right ABI version.
As a hint, the ABI version is encoded in the compiler name on your host.