ARM compilation error, VPF registered

转自: 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 gcc  compilation  arm share | improve this question edited  Mar 17 '12 at 21:51 asked  Mar 17 '12 at 21:09 Jim 768 8 28

1   Full compile and link command lines please.. –  blueshift  Mar 17 '12 at 21:18   I have added the full compile error summary. –  Jim  Mar 17 '12 at 21:29 add comment

4 Answers

active oldest votes

up vote 6 down vote accepted

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. share | improve this answer answered  Mar 17 '12 at 21:36 ams 6,917 5 25

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? –  Jim  Mar 17 '12 at 21:53 1   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. –  ams  Mar 17 '12 at 23:42 add comment

up vote 2 down vote	Also the error can be solved by adding several flags, like -marm -mthumb-interwork. It was helpful for me to avoid this same error. share | improve this answer edited  May 29 '12 at 6:44 Botz3000 21.4k 5 33 65 answered  May 28 '12 at 11:18 AVG 23 3
	add comment

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. share | improve this answer answered  Mar 17 '12 at 21:36 blueshift 2,748 9 22
	add comment

up vote 1 down vote

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 STM32F4Discovery and FPU not working Views (1321) Reply (4) State ( resolved)      Post a reply Replies  Tokio 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 Add this to Google Bookmarks Add this to Mister Wong Add this to Izeby Share this on Tipd Share this on PFBuzz Share this on FriendFeed Mark this on BlogMarks Blog this on Blogger Submit this to Twittley Share this on Fwisp Moo this on DesignMoo! Share this on BobrDobr Add this to Yandex.Bookmarks Add this to Memory.ru Add this to 100 bookmarks Add this to MyPlace Submit this to Hacker News Send this page to Print Friendly Bump this on DesignBump Add this to Ning Post this to Identica Save this to Xerpi Share this on Wikio Tip this to TechMeme Sphinn this on Sphinn Post this to Posterous Grind this! on Global Grind Ping this on Ping.fm Submit this to NUjij Submit this to eKudos Submit this to Netvouz Submit this to Netvibes Share this on Fleck Share this on Blogosphere News Blend this! Add this to Wykop! Engage with this article! Share this on Hyves Push this on Pusha Bookmarks this on Hatena Bookmarks Store this link on MyLinkVault Submit this to SlashDot Add to a lense on Squidoo Submit this story to Propeller Submit this to FAQpal Clip this to Evernote Submit this to Meneame Submit this to Bitacoras Submit this link to JumpTags Share this on Bebo Submit tip to N4G Submit this to Strands Share this on Tumblr Add this to Stumpedia Post this to Current Share this on Plurk  fm 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 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 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 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