Errore di compilazione ARM, registrazione VFP utilizzata da eseguibile, non file object

Ho avuto questo problema negli ultimi giorni e non riesco a capire cosa stia realmente succedendo qui, o qual è il problema.

Ho un makefile con queste bandiere:

CC = arm-linux-gnueabihf-gcc-4.6 FLAGS = -O3 -march=armv7-a -mtune=cortex-a9 -mfpu=neon -ftree-vectorize -mfloat-abi=softfp -std=gnu99 

Ho una libreria in un file .a, che ha alcuni file object, tutto ciò che devo fare è collegarli con il mio eseguibile. Conosco i prototipi e tutto il resto, l’unica cosa che si lamenta è la seguente:

 /usr/bin/ld: error: *EXECUTABLE* uses VFP register arguments, *OBJECTFILE* does not /usr/bin/ld: failed to merge target specific data of file *OBJECTFILE* 

Quando non uso -mfloat-abi = softfp, ottengo un altro errore relativo ai registri in virgola mobile.

Qualcuno ha idea di cosa sta causando questo, e cosa posso fare per risolvere questo problema, ad esempio facendo in modo che il mio eseguibile non usi gli argomenti del Virtual Floating Point Register?

 [email protected]:~/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(ao) does not /usr/bin/ld: failed to merge target specific data of file ../baseline/lib.a(ao) /usr/bin/ld: error: perf_test uses VFP register arguments, ../baseline/lib.a(bo) does not /usr/bin/ld: failed to merge target specific data of file ../baseline/lib.a(bo) /usr/bin/ld: error: perf_test uses VFP register arguments, ../baseline/lib.a(co) does not /usr/bin/ld: failed to merge target specific data of file ../baseline/lib.a(co) /usr/bin/ld: error: perf_test uses VFP register arguments, ../baseline/lib.a(do) does not /usr/bin/ld: failed to merge target specific data of file ../baseline/lib.a(do) /usr/bin/ld: error: perf_test uses VFP register arguments, ../baseline/lib.a(eo) does not /usr/bin/ld: failed to merge target specific data of file ../baseline/lib.a(eo) /usr/bin/ld: error: perf_test uses VFP register arguments, ../baseline/lib.a(fo) does not /usr/bin/ld: failed to merge target specific data of file ../baseline/lib.a(fo) collect2: ld returned 1 exit status make: *** [perf_test] Error 1 

La tripletta target indica che il compilatore è configurato per l’ABI hard-float . Ciò significa che la libreria libgcc sarà anche hardfp. Il messaggio di errore indica che almeno parte del sistema utilizza ABI soft-float .

Se il compilatore ha abilitato il multilib (puoi dirlo con -print-multi-lib ), puoi usare -mfloat-abi=softfp , ma se non è così -mfloat-abi=softfp non ti aiuterà molto: gcc genererà volentieri codice softfp, ma quindi non ci sarà nessuna libgcc compatibile con cui creare un collegamento.

Fondamentalmente, hardfp e softfp non sono compatibili. È necessario configurare l’intero sistema in un modo o nell’altro.

EDIT: alcune distro sono, o saranno, “multiarch”. Se si dispone di uno di questi, è ansible installare entrambi gli ABI contemporaneamente, ma ciò avviene raddoppiando tutto – i problemi di compatibilità esistono ancora.

Ho trovato su un sistema hardfloat arm dove gli bin bin e gli gcc di glibc erano crosscompiled, usando gcc si dà lo stesso errore.

Viene risolto esportando -mfloat-abi=hard to flags, quindi gcc compila senza errori.

Inoltre l’errore può essere risolto aggiungendo diversi flag, come -marm -mthumb-interwork . È stato utile per me evitare questo stesso errore.

Questa è una supposizione, ma potrebbe essere necessario fornire alcune o tutte le opzioni relative al floating point per la fase di collegamento.

Usa anche le stesse opzioni del compilatore per il collegamento.

Esempio:

 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 

Nel mio caso CFLAGS = -O0 -g -Wall -I. -mcpu=cortex-m4 -mthumb -mfpu=fpv4-sp-d16 -mfloat-abi=soft CFLAGS = -O0 -g -Wall -I. -mcpu=cortex-m4 -mthumb -mfpu=fpv4-sp-d16 -mfloat-abi=soft ha aiutato. Come puoi vedere, l’ho usato per il mio stm32f407.

Ho riscontrato il problema utilizzando Atollic per ARM su STM32F4 (suppongo si applichi a tutti gli STM32 con FPU).

L’uso del SW in virgola mobile non ha funzionato bene (compilando quindi correttamente).

Quando STM32cubeMX genera codice per TrueStudio (Atollic), non imposta un’unità FPU in impostazioni di compilazione C / C ++ (non è sicuro del codice generato per altri IDE).

Impostare una FPU in “Destinazione” per (nelle impostazioni di costruzione delle proprietà del progetto):

  • assembler
  • Compilatore C
  • C Linker

Quindi hai la possibilità di mixare HW / SW fp o usare HW.

Le righe di comando generate vengono aggiunte con questo per la destinazione desiderata:

 -mfloat-abi=hard -mfpu=fpv4-sp-d16 

arm atolico

Stavo affrontando lo stesso problema. Stavo cercando di creare un’applicazione linux per Cyclone V FPGA-SoC. Ho affrontato il problema come di seguito:

 Errore:  utilizza gli argomenti del registro VFP, main.o no

Stavo usando la toolchain arm-linux-gnueabihf-g++ fornita dallo strumento di progettazione software embedded di altera.

Viene risolto esportando: mfloat-abi=hard to flags, quindi arm-linux-gnueabihf-g++ compila senza errori. Includere anche le bandiere in CC e LD .

Nel mio caso particolare -g -march=armv7-a -mfloat-abi=hard -mfpu=neon -marm -mthumb-interwork funzionato.

Questa risposta potrebbe apparire non correlata alla superficie, ma esiste una causa indiretta di questo messaggio di errore.

Innanzitutto, il messaggio di errore “Usa registro VFP …” è causato direttamente dalla combinazione di opzioni mfloat-abi = soft e mfloat-abi = hard all’interno della build. Questa impostazione deve essere coerente per tutti gli oggetti che devono essere collegati. Questo fatto è ben trattato nelle altre risposte a questa domanda.

La causa indiretta di questo errore può essere dovuta all’editor di Eclipse che viene confuso da un errore autoinflitto nel file “.cproject” del progetto. L’editor di Eclipse frequentemente riscrive i collegamenti ai file e talvolta si interrompe quando si apportano modifiche alle strutture delle directory o ai percorsi dei file. Questo può anche influenzare le impostazioni del percorso per il tuo compilatore gcc – e solo per un sottoinsieme dei file del tuo progetto. Anche se non sono ancora sicuro di quale sia la causa di questo errore, la sostituzione del file .cproject con una copia di backup ha risolto il problema per me. Nel mio caso ho notato errori .java.null.pointer dopo l’aggiunta di un percorso di directory di inclusione e ho iniziato a ricevere i messaggi “Errore registro VFP” dal nulla. Nel log di compilazione ho notato che un diverso percorso del compilatore gcc veniva usato per alcune delle mie risorse che erano locali nello spazio di lavoro, ma non tutte !? I due compilatori gcc utilizzavano diverse impostazioni float per ragioni sconosciute – da qui l’errore di registro VFP.

Ho confrontato le impostazioni di .cproject con una copia più vecchia e ho osservato differenze nelle voci relative alle fonti che causavano il problema, anche se l’override delle impostazioni del progetto era disabilitata. Sostituendo il file .cproject con la vecchia versione il problema è andato via, e sto lasciando questa risposta come promemoria di cosa è successo.