Gccツールチェーンを構築する場合、arm-elfまたはarm-none-eabiとして構築する可能性がありますが、違いは何ですか?
私は今日eabiを使用していますが、それは他の誰もがそうしているように見えるからです...しかし、それは本当に悪い議論なので、違いを理解することは本当に素晴らしいことです。
注:このツールチェーンは、stm32のようなCortex-M3ベースのmcu:sのコードをクロスコンパイルします。
ありがとう
一部のリンク:
EABI:
エルフ:
各アーキテクチャまたはアーキテクチャ/ OSカップルには、ABIがあります。 ABI(アプリケーションバイナリインターフェイス)は、関数の呼び出し方法、syscalls番号、渡された引数、使用できるレジスタを記述します...
Abiは、コンパイラーがアセンブラーを生成する方法を説明します。
アセンブラのみを使用する場合は、ABIを気にする必要はありません。
arm-elfとarm-none-eabiは、Arm ABIの2つのバージョンを使用します。 eabiツールチェーンは新しいリビジョンを使用しますが、elfも生成するため、arm-elf-eabiと呼ばれることもあります。
ここ は優れた説明です。
ツールチェーンは緩やかな命名規則に従います:Arch [-vendor] [-os] -eabi
Arch refers to target architecture (which in our case is ARM)
vendor refers to toolchain supplier
os refers to the target operating system
eabi refers to Embedded Application Binary Interface
いくつかの例:
arm-none-eabi:このツールチェーンは、ARMアーキテクチャをターゲットとし、ベンダーを持たず、オペレーティングシステムをターゲットにせず、ARM EABIに準拠しています。
arm-none-linux-gnueabi:このツールチェーンは、ARMアーキテクチャを対象とし、ベンダーを持たず、Linuxオペレーティングシステムで実行されるバイナリを作成し、GNU = EABI。ARMベースのLinuxシステムをターゲットにするために使用されます。
私の知る限り:
arm-elf toolchainは、elf形式(Linux ABIの例)の実行をサポートする一部のOSのobjコードを生成します。 OSがプログラムの実行を制御します。
arm-none-eabi toolchainは、マイクロコントローラーまたはマイクロプロセッサー用のobjコードを生成します(ベアメタルの場合、これはEABI-組み込みABIになります)。このコードはMCのクリーンフラッシュにダウンロードされ、MCのコアは電源投入後に実行を開始します。 OSなし、拡張コマンドセット、共有モジュールとリンクする可能性はありません。
ARM EABIは、ARMによって作成された標準であり、異なるツールチェーンが互換性のあるオブジェクトを作成できるようにします。 。