eabi編譯選項

Ⅰ 交叉編譯器 arm-linux-gnueabi 和 arm-linux-gnuea

一. 什麼是ABI和EABI
1) ABI: 二進制應用程序介面(Application Binary Interface (ABI) for the ARM Architecture)
在計算機中，應用二進制介面描述了應用程序（或者其他類型）和操作系統之間或其他應用程序的低級介面.
ABI涵蓋了各種細節，如：
數據類型的大小、布局和對齊;
調用約定（控制著函數的參數如何傳送以及如何接受返回值），例如，是所有的參數都通過棧傳遞，還是部分參數通過寄存器傳遞；哪個寄存器用於哪個函數參數；通過棧傳遞的第一個函數參數是最先push到棧上還是最後；
系統調用的編碼和一個應用如何向操作系統進行系統調用；
以及在一個完整的操作系統ABI中，目標文件的二進制格式、程序庫等等。
一個完整的ABI，像Intel二進制兼容標准 (iBCS) ，允許支持它的操作系統上的程序不經修改在其他支持此ABI的操作體統上運行。
ABI不同於應用程序介面（API），API定義了源代碼和庫之間的介面，因此同樣的代碼可以在支持這個API的任何系統中編譯，ABI允許編譯好的目標代碼在使用兼容ABI的系統中無需改動就能運行。
2) EABI: 嵌入式ABI
嵌入式應用二進制介面指定了文件格式、數據類型、寄存器使用、堆積組織優化和在一個嵌入式軟體中的參數的標准約定。
開發者使用自己的匯編語言也可以使用EABI作為與兼容的編譯器生成的匯編語言的介面。
支持EABI的編譯器創建的目標文件可以和使用類似編譯器產生的代碼兼容，這樣允許開發者鏈接一個由不同編譯器產生的庫。
EABI與關於通用計算機的ABI的主要區別是應用程序代碼中允許使用特權指令，不需要動態鏈接（有時是禁止的），和更緊湊的堆棧幀組織用來節省內存。廣泛使用EABI的有Power PC和ARM.
二. gnueabi相關的兩個交叉編譯器: gnueabi和gnueabihf
在debian源里這兩個交叉編譯器的定義如下:
gcc-arm-linux-gnueabi – The GNU C compiler for armel architecture
gcc-arm-linux-gnueabihf – The GNU C compiler for armhf architecture
可見這兩個交叉編譯器適用於armel和armhf兩個不同的架構, armel和armhf這兩種架構在對待浮點運算採取了不同的策略(有fpu的arm才能支持這兩種浮點運算策略)
其實這兩個交叉編譯器只不過是gcc的選項-mfloat-abi的默認值不同. gcc的選項-mfloat-abi有三種值soft,softfp,hard(其中後兩者都要求arm里有fpu浮點運算單元,soft與後兩者是兼容的，但softfp和hard兩種模式互不兼容)：
soft : 不用fpu進行浮點計算，即使有fpu浮點運算單元也不用,而是使用軟體模式。
softfp : armel架構(對應的編譯器為gcc-arm-linux-gnueabi)採用的默認值，用fpu計算，但是傳參數用普通寄存器傳，這樣中斷的時候，只需要保存普通寄存器，中斷負荷小，但是參數需要轉換成浮點的再計算。
hard : armhf架構(對應的編譯器gcc-arm-linux-gnueabihf)採用的默認值，用fpu計算，傳參數也用fpu中的浮點寄存器傳，省去了轉換, 性能最好，但是中斷負荷高。

Ⅱ 如何設置NDK的編譯選項

1. 概述

首先回顧一下 Android NDK 開發中，Android.mk 和Application.mk 各自的職責。

Android.mk，負責配置如下內容：

（1） 模塊名（LOCAL_MODULE）

（2） 需要編譯的源文件（LOCAL_SRC_FILES）

（3） 依賴的第三方庫（LOCAL_STATIC_LIBRARIES，LOCAL_SHARED_LIBRARIES）

（4） 編譯/鏈接選項（LOCAL_LDLIBS、LOCAL_CFLAGS）

Application.mk，負責配置如下內容：

（1） 目標平台的ABI類型（默認值：armeabi）（APP_ABI）

（2） Toolchains（默認值：GCC 4.8）

（3） C++標准庫類型（默認值：system）（APP_STL）

（4） release/debug模式（默認值：release）

由此我們可以看到，本文所涉及的編譯選項在Android.mk和Application.mk中均有出現，下面我們將一個個詳細介紹。

2. APP_ABI

ABI全稱是：Application binary interface，即：應用程序二進制介面，它定義了一套規則，允許編譯好的二進制目標代碼在所有兼容該ABI的操作系統和硬體平台中無需改動就能運行。（具體的定義請參考網路或者維基網路）

由上述定義可以判斷，ABI定義了規則，而具體的實現則是由編譯器、CPU、操作系統共同來完成的。不同的CPU晶元（如：ARM、Intel x86、MIPS）支持不同的ABI架構，常見的ABI類型包括：armeabi，armeabi-v7a，x86，x86_64，mips，mips64，arm64-v8a等。

這就是為什麼我們編譯出來的可以運行於Windows的二進製程序不能運行於Mac OS/Linux/Android平台了，因為CPU晶元和操作系統均不相同，支持的ABI類型也不一樣，因此無法識別對方的二進製程序。

而我們所說的「交叉編譯」的核心原理也跟這些密切相關，交叉編譯，就是使用交叉編譯工具，在一個平台上編譯生成另一個平台上的二進制可執行程序，為什麼可以做到？因為交叉編譯工具實現了另一個平台所定義的ABI規則。我們在Windows/Linux平台使用Android NDK交叉編譯工具來編譯出Android平台的庫也是這個道理。

這里給出最新 Android NDK 所支持的ABI類型及區別：

下面是我總結的一些常用的CFLAGS編譯選項：

（1）通用的編譯選項

-O2 編譯優化選項，一般選擇O2，兼顧了優化程度與目標大小

-Wall 打開所有編譯過程中的Warning

-fPIC 編譯位置無關的代碼，一般用於編譯動態庫

-shared 編譯動態庫

-fopenmp 打開多核並行計算，

-Idir 配置頭文件搜索路徑，如果有多個-I選項，則路徑的搜索先後順序是從左到右的，即在前面的路徑會被選搜索

-nostdinc 該選項指示不要標准路徑下的搜索頭文件，而只搜索-I選項指定的路徑和當前路徑。

--sysroot=dir 用dir作為頭文件和庫文件的邏輯根目錄，例如，正常情況下，如果編譯器在/usr/include搜索頭文件，在/usr/lib下搜索庫文件，它將用dir/usr/include和dir/usr/lib替代原來的相應路徑。

-llibrary 查找名為library的庫進行鏈接

-Ldir 增加-l選項指定的庫文件的搜索路徑，即編譯器會到dir路徑下搜索-l指定的庫文件。

-nostdlib 該選項指示鏈接的時候不要使用標准路徑下的庫文件

（2） ARM平台相關的編譯選項

-marm -mthumb 二選一，指定編譯thumb指令集還是arm指令集

-march=name 指定特定的ARM架構，常用的包括：-march=armv6， -march=armv7-a

-mfpu=name 給出目標平台的浮點運算處理器類型，常用的包括：-mfpu=neon，-mfpu=vfpv3-d16

-mfloat-abi=name 給出目標平台的浮點預算ABI，支持的參數包括：「soft」, 「softfp」 and 「hard」

Ⅲ 用gcc 4.7.1的源代碼編譯出來arm-eabi-gcc。編譯的時候指定了cpu類型，但是編譯出來的程序，不能運行。

去掉 -march=arm6試下吧。

Ⅳ arm-none-eabi-gcc對比mdk編譯效率和實際效果怎麼樣

eabi是arm新的二進制文件介面的標准，elf是二進制目標文件的格式，而名稱為arm-elf的編譯器一般是老的OABI介面，裸奔程序到影響不大，在嵌入式linux中，要注意系統的介面，是老的oabi還是eabi，新的內核一般是eabi介面，但編譯內核時會有兼用oab...

Ⅳ 如何使用arm-none-eabi-gcc 編譯

交叉編譯環境搭建後 arm-linux-gcc -v 顯示 No such file or directory 使用which命令可以找到，環境變數沒有問題，更詳細的描述問題就是which找到的命令所在的目錄下的所有命令都是同樣的問題。

Ⅵ v7a軟體和v8a軟體的區別

v7a和v8a區別：

armeabi默認選項，32位，支持基於ARM*v5TE的設備，支持軟浮點運算（不支持硬體輔助的浮點計算），支持所有ARM*設備，armeabi-v7a32位，支持基於ARM*v7的設備，支持硬體FPU指令，支持硬體浮點運算。

armeabi-v8a64位，支持基於ARM*v8的設備，支持硬體FPU指令，支持硬體浮點運算不同手機由於cpu的不同，使用不同的驅動。

ABI:指應用基於哪種指令集來進行編譯，ABI總共有四種，分別是armeabi、armeabi-v7a、mips、x86，它們都是表示cpu的類型。

為了減小apk體積，只保留armeabi和armeabi-v7a兩個文件夾，並保證這兩個文件夾中.so數量一致。

對只提供armeabi版本的第三方.so，原樣復制一份到armeabi-v7a文件夾。

早期的Android系統幾乎只支持ARMv5的CPU架構，現在支持7種！

Android系統目前支持以下七種不同的CPU架構：ARMv5，ARMv7(從2010年起)，x86(從2011年起)，MIPS(從2012年起)，ARMv8，MIPS64和x86_64(從2014年起)，每一種都關聯著一個相應的ABI。

應用程序二進制介面（ApplicationBinaryInterface）定義了二進制文件（尤其是.so文件）如何運行在相應的系統平台上，從使用的指令集，內存對齊到可用的系統函數庫。

在Android系統上，每一個CPU架構對應一個ABI：armeabi，armeabi-v7a，x86，mips，arm64- v8a，mips64，x86_64。

Ⅶ 在ubuntu系統連接jz2440開發板 出現Illegal instruction

我幫你查了下，看看有沒有用。雖然是轉載的~希望能幫上忙
Illegal instruction的解決方法

最新解決方法：
把/usr/local/arm/compiler/arm-none-linux-gnueabi/libc/armv4t/lib目錄(也就是你的編譯器的庫目錄)下
的所有文件拷貝到目標板子的根目錄的lib目錄下就好了。
這樣無論你的hello是動態編譯還是靜態編譯，跑起來都不會有Illegal instruction的問題。
////////////////////////////////
老的解決方法：
開發板配置: ARM9 + linux-3.6.30
編譯器：arm-linux-4.3.2
在移植好jffs2文件系統以後，當然想寫個hello world 來驗證一下自己的成果了。好，開始：
1.編輯編譯
#vi hello.c
#include <stdio.h>
int main(void)
{
printf("welcome to my rootfs!/n");
return 0;
}
#arm-linux-gcc –o hello hello.c
2.把hello復制到用來製作文件系統的文件夾，製作文件系統rootfs.jffs2,下載運行，開發板能夠成功啟動，能夠出現shell交互界面。這點肯定地說明busybox是沒有問題的。運行hello
./hello出現：
Illegal instruction
從網上找了很多資料，大部分把責任歸於EABI，但我想想，既然kernel和busybox都能正常啟動，那它們都應該是eabi編譯的了，hello也肯定是eabi的，因為他們都是用arm-linux-4.3.2編譯的(編譯內核的時候make menuconfig要選山EABI選項).所以網上大部分資料都不適合解決我遇到的問題。但最終還是找到了一邊能夠幫我解決問題的文章：
http://hi..com/caicry/blog/item/ede3b8fa01ebc89059ee908a.html
雖然他還是把問題歸咎於EABI，但是卻給我指點了解決問題的方向。
既然busybox（這里的busybox是指編譯busybox-1.15.2生成的busybox二進制文件）能夠成功運行，hello不能運行，那就看看他們的區別：
#file buxybox
busybox: ELF 32-bit LSB executable, ARM, version 1 (SYSV),statically linked, for GNU/Linux 2.6.14, stripped
#file hello
# file hello
hello: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped
這時候恍然大悟了，hello在ram+linux系統上找不到運行所需的動態庫，所以Illegal instruction。重新編譯hello.c
#gcc –static –o hello hello.c
#file hello
hello_static: ELF 32-bit LSB executable, ARM, version 1 (SYSV),statically linked, for GNU/Linux 2.6.14, not stripped
重新製作jffs2文件系統，下載運行：
#hello出現
welcome to my rootfs!

完！

現在EABI已經開始在嵌入式中流行起來，確保軟體的EABI匹配性，應該注意下面幾點：
1. 編譯kernel的時候要選上EABI。
2. 交叉編譯的所有的軟體都要用支持EABI的編譯器(例如arm-linux-4.3.2)來編譯。

Ⅷ linux下如何把一個.c文件通過arm-none-eabi-交叉編譯生成一個.bin的文件然後在qemu上運行

eabi標準的要好些，可能arm-linux-gcc就是arm-none-linux-gnueabi的一個鏈接
終於，郁悶已久的問題攻破了，用了三種配置交叉編譯的方法，最終在開發板上實現成功了，現在想一想，有的時候真的也是運氣。

之前已經試驗過使用arm-linux-gcc-3.4.1配置交叉編譯編譯環境，配置成功了，在開發板上失敗了~

後來使用腳本創建交叉編譯環境（crosstool-0.43），配置成功了（這個用了相當長的時間），在開發板上失敗了~

Ⅸ 交叉編譯器 arm-linux-gnueabi 和 arm-linux-gnueabihf 的區別

自己之前一直沒搞清楚這兩個交叉編譯器到底有什麼問題,特意google一番,總結如下,希望能幫到道上和我有同樣困惑的兄弟…..
一. 什麼是ABI和EABI
1) ABI: 二進制應用程序介面(Application Binary Interface (ABI) for the ARM Architecture)
在計算機中，應用二進制介面描述了應用程序（或者其他類型）和操作系統之間或其他應用程序的低級介面.
ABI涵蓋了各種細節，如：
數據類型的大小、布局和對齊;
調用約定（控制著函數的參數如何傳送以及如何接受返回值），例如，是所有的參數都通過棧傳遞，還是部分參數通過寄存器傳遞；哪個寄存器用於哪個函數參數；通過棧傳遞的第一個函數參數是最先push到棧上還是最後；
系統調用的編碼和一個應用如何向操作系統進行系統調用；
以及在一個完整的操作系統ABI中，目標文件的二進制格式、程序庫等等。
一個完整的ABI，像Intel二進制兼容標准 (iBCS) ，允許支持它的操作系統上的程序不經修改在其他支持此ABI的操作體統上運行。
ABI不同於應用程序介面（API），API定義了源代碼和庫之間的介面，因此同樣的代碼可以在支持這個API的任何系統中編譯，ABI允許編譯好的目標代碼在使用兼容ABI的系統中無需改動就能運行。
2) EABI: 嵌入式ABI
嵌入式應用二進制介面指定了文件格式、數據類型、寄存器使用、堆積組織優化和在一個嵌入式軟體中的參數的標准約定。
開發者使用自己的匯編語言也可以使用EABI作為與兼容的編譯器生成的匯編語言的介面。
支持EABI的編譯器創建的目標文件可以和使用類似編譯器產生的代碼兼容，這樣允許開發者鏈接一個由不同編譯器產生的庫。
EABI與關於通用計算機的ABI的主要區別是應用程序代碼中允許使用特權指令，不需要動態鏈接（有時是禁止的），和更緊湊的堆棧幀組織用來節省內存。廣泛使用EABI的有Power PC和ARM.
二. gnueabi相關的兩個交叉編譯器: gnueabi和gnueabihf
在debian源里這兩個交叉編譯器的定義如下:
gcc-arm-linux-gnueabi – The GNU C compiler for armel architecture
gcc-arm-linux-gnueabihf – The GNU C compiler for armhf architecture
可見這兩個交叉編譯器適用於armel和armhf兩個不同的架構, armel和armhf這兩種架構在對待浮點運算採取了不同的策略(有fpu的arm才能支持這兩種浮點運算策略)
其實這兩個交叉編譯器只不過是gcc的選項-mfloat-abi的默認值不同. gcc的選項-mfloat-abi有三種值soft,softfp,hard(其中後兩者都要求arm里有fpu浮點運算單元,soft與後兩者是兼容的，但softfp和hard兩種模式互不兼容)：
soft : 不用fpu進行浮點計算，即使有fpu浮點運算單元也不用,而是使用軟體模式。
softfp : armel架構(對應的編譯器為gcc-arm-linux-gnueabi)採用的默認值，用fpu計算，但是傳參數用普通寄存器傳，這樣中斷的時候，只需要保存普通寄存器，中斷負荷小，但是參數需要轉換成浮點的再計算。
hard : armhf架構(對應的編譯器gcc-arm-linux-gnueabihf)採用的默認值，用fpu計算，傳參數也用fpu中的浮點寄存器傳，省去了轉換, 性能最好，但是中斷負荷高。
把以下測試使用的c文件內容保存成mfloat.c：
#include <stdio.h>
int main(void)
{
double a,b,c;
a = 23.543;
b = 323.234;
c = b/a;
printf(「the 13/2 = %f\n」, c);
printf(「hello world !\n」);
return 0;
}
1)使用arm-linux-gnueabihf-gcc編譯，使用「-v」選項以獲取更詳細的信息:
# arm-linux-gnueabihf-gcc -v mfloat.c
COLLECT_GCC_OPTIONS=』-v』 『-march=armv7-a』 『-mfloat-abi=hard』 『-mfpu=vfpv3-d16′ 『-mthumb』
-mfloat-abi=hard，可看出使用hard硬體浮點模式。
2)使用arm-linux-gnueabi-gcc編譯:
# arm-linux-gnueabi-gcc -v mfloat.c
COLLECT_GCC_OPTIONS=』-v』 『-march=armv7-a』 『-mfloat-abi=softfp』 『-mfpu=vfpv3-d16′ 『-mthumb』
-mfloat-abi=softfp，可看出使用softfp模式。
三. 拓展閱讀
下文闡述了ARM代碼編譯時的軟浮點(soft-float)和硬浮點(hard-float)的編譯以及鏈接實現時的不同。從VFP浮點單元的引入到軟浮點(soft-float)和硬浮點(hard-float)的概念
VFP (vector floating-point)
從ARMv5開始，就有可選的 Vector Floating Point (VFP) 模塊，當然最新的如 Cortex-A8, Cortex-A9 和 Cortex-A5 可以配置成不帶VFP的模式供晶元廠商選擇。
VFP經過若干年的發展，有VFPv2 (一些 ARM9 / ARM11)、 VFPv3-D16（只使用16個浮點寄存器，默認為32個）和VFPv3+NEON (如大多數的Cortex-A8晶元) 。對於包含NEON的ARM晶元，NEON一般和VFP公用寄存器。
硬浮點Hard-float
編譯器將代碼直接編譯成發射給硬體浮點協處理器（浮點運算單元FPU）去執行。FPU通常有一套額外的寄存器來完成浮點參數傳遞和運算。
使用實際的硬體浮點運算單元FPU當然會帶來性能的提升。因為往往一個浮點的函數調用需要幾個或者幾十個時鍾周期。
軟浮點 Soft-float
編譯器把浮點運算轉換成浮點運算的函數調用和庫函數調用，沒有FPU的指令調用，也沒有浮點寄存器的參數傳遞。浮點參數的傳遞也是通過ARM寄存器或者堆棧完成。
現在的Linux系統默認編譯選擇使用hard-float，即使系統沒有任何浮點處理器單元，這就會產生非法指令和異常。因而一般的系統鏡像都採用軟浮點以兼容沒有VFP的處理器。
armel ABI和armhf ABI
在armel中，關於浮點數計算的約定有三種。以gcc為例，對應的-mfloat-abi參數值有三個：soft,softfp,hard。
soft是指所有浮點運算全部在軟體層實現，效率當然不高，會存在不必要的浮點到整數、整數到浮點的轉換，只適合於早期沒有浮點計算單元的ARM處理器；
softfp是目前armel的默認設置，它將浮點計算交給FPU處理，但函數參數的傳遞使用通用的整型寄存器而不是FPU寄存器；
hard則使用FPU浮點寄存器將函數參數傳遞給FPU處理。
需要注意的是，在兼容性上，soft與後兩者是兼容的，但softfp和hard兩種模式不兼容。
默認情況下，armel使用softfp，因此將hard模式的armel單獨作為一個abi，稱之為armhf。
而使用hard模式，在每次浮點相關函數調用時，平均能節省20個CPU周期。對ARM這樣每個周期都很重要的體系結構來說，這樣的提升無疑是巨大的。
在完全不改變源碼和配置的情況下，在一些應用程序上，使用armhf能得到20%——25%的性能提升。對一些嚴重依賴於浮點運算的程序，更是可以達到300%的性能提升。
Soft-float和hard-float的編譯選項
在CodeSourcery gcc的編譯參數上，使用-mfloat-abi=name來指定浮點運算處理方式。-mfpu=name來指定浮點協處理的類型。
可選類型如fpa，fpe2，fpe3，maverick，vfp，vfpv3，vfpv3-fp16，vfpv3-d16，vfpv3-d16-fp16，vfpv3xd，vfpv3xd-fp16，neon，neon-fp16，vfpv4，vfpv4-d16，fpv4-sp-d16，neon-vfpv4等。
使用-mfloat-abi=hard (等價於-mhard-float) -mfpu=vfp來選擇編譯成硬浮點。使用-mfloat-abi=softfp就能兼容帶VFP的硬體以及soft-float的軟體實現，運行時的連接器ld.so會在執行浮點運算時對於運算單元的選擇，
是直接的硬體調用還是庫函數調用，是執行/lib還是/lib/vfp下的libm。-mfloat-abi=soft （等價於-msoft-float）直接調用軟浮點實現庫。
在ARM RVCT工具鏈下，定義fpu模式：
–fpu softvfp
–fpu softvfp+vfpv2
–fpu softvfp+vfpv3
–fpu softvfp+vfpv_fp16
–fpu softvfp+vfpv_d16
–fpu softvfp+vfpv_d16_fp16.
定義浮點運算類型
–fpmode ieee_full : 所有單精度float和雙精度double的精度都要和IEEE標准一致，具體的模式可以在運行時動態指定；
–fpmode ieee_fixed ： 舍入到最接近的實現的IEEE標准，不帶不精確的異常；
–fpmode ieee_no_fenv ：舍入到最接近的實現的IEEE標准，不帶異常；
–fpmode std ：非規格數flush到0、舍入到最接近的實現的IEEE標准，不帶異常；
–fpmode fast ： 更積極的優化，可能會有一點精度損失。

Ⅹ 怎麼關閉Linux的EABI選項，Kernel Features

kernel future