ARM compilation error, VPF registered

Question

转自: http://stackoverflow.com/questions/9753749/arm-compilation-error-vpf-registered-used-by-executable-not-object-file

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

ams · Accepted Answer · 2012-03-17 21:36:57Z

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 usingsoft-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 bothABIs at once, but that's done by doubling everything up -- the compatibility issues still exist.

When i compile with -hard then it removes the executable and code that I wrote, but still errors with the library. My question is basically pretend I don't know anything about anything. What is happening here, and why?
Your libraries and/or executable are not compatible because they use different procedure calling conventions: one passes float values in VFP registers and the other passes them in core registers.

blueshift · Answer 2 · 2012-03-17 21:36:00Z

up vote 1 down vote

This is guesswork, but you may need to supply some or all of the floating point related switches for the link stage as well.

answered Mar 17 '12 at 21:36

blueshift
2,748 9 22

add comment

score 1 · Answer 3

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.

转自: http://www.coocox.org/forum/topic.php?id=1763

Replies
- Tokio
  1. 11 months ago
- I"m a newbie about STM32F4Discovery and CoIDE.
  
  Please give me any suggestion to resolve a problem I encountered.
  
  I made a very simple program to control DDS direct digital synthesizer where float varibale is used.
  
  Build is OK with "FPU hard", "FPU soft", as well as "not use FPU".
  
  However the binary works only with not use FPU. Others entered infinte loop of exception handler I confirmed by Debugger.
  
  In my source I declared variables like this;
  
  float Freq_dds;
  
  Thank you in advance.
  
  Tokio

fm
1. 11 months ago

The FPU is not enabled by default.

You need to enable it, otherwise you end up in the Hardfault handler...

I'm not using Coocox, so I'm not sure how it is handled there. If it does not select an appropriate startup code by itself, you need to do it. Here two examples:

void cortexm4f_enable_fpu() {
    /* set CP10 and CP11 Full Access */
    SCB->CPACR |= ((3UL << 10*2)|(3UL << 11*2));
}  Or, in assembly code:   /*enable fpu begin*/
ldr     r0, =0xe000ed88   /*; enable cp10,cp11 */
ldr     r1,[r0]
ldr     r2, =0xf00000
orr     r1,r1,r2
str     r1,[r0]
/*enable fpu end*/


Take care that your compiler setting ("softfp" or "hard") matches that
of the math library you link in. Otherwise you are in for the next surprise.

- Tokio
  1. 11 months ago
- Hello fm,
  
  I"ve been away from home for almost one week.
  
  Thank you very much for your comments.
  
  I wrote your code into my main.c, then it works fine.
  
  However, CoIDE has very strange behaviour. In my Project set-up, I chosen "FPUhard", then "__FPU_USED" definiton appeared in Project set-up pain. I thought it should be now OK since necessary statrt-up will be defined. But it IS NOT!
  
  I"m very much afraid that such things might happen in any other feature of STM32F4 by using CoIDE.
  
  Regards,
  
  Tokio
- fm
  1. 11 months ago
- Frankly, I don't use CoIDE, so I can't tell you the way CoIDE is supposed to do it.
  
  Usually, this FPU initialization is located in the startup (i.e. "between" reset and main). Other IDE's either select the appropriate startup file (assembler) automatically, or let you chose.
  
  Maybe this is moving into the IDE sometime soon. The __FPU_USED macro is an indication that some efforts were made.
- Grace
  1. 11 months ago
- Hello all,
  
  First of all, I apologize on the behalf of CooCox for the inconvenience caused to you. We will update the component later. Before that users can enable the FPU in the code as following:
  
  in source code:
  *((volatile unsigned long*)0xE000ED88) = 0xF << 20;
  
  in assembly code:
  /*enable fpu begin*/
  __asm(" LDR.W R0, =0xE000ED88\n"
          " LDR R1, [R0]\n"
          " ORR R1, R1, #(0xF << 20)\n"
          " STR R1, [R0]");
  /*enable fpu end*/
  
  Best Regards
  
  Grace

ARM compilation error, VPF registered

4 Answers

STM32F4Discovery and FPU not working

Replies

“相关推荐”对你有帮助么？