ABI（Application Binary Interface）は、高レベル言語の低レベル概念と特定のハードウェア/ OSプラットフォームのマシンコードの能力。次のようなものが含まれます。
- c/C++/Fortran/... データ型がメモリ内でどのようにレイアウトされるか（データサイズ/アライメント）
- どのようにネストされているか関数呼び出し動作（関数の呼び出し元に戻る方法に関する情報が保存されている場所と方法、CPUレジスターやメモリー関数引数が渡される場所）
- 方法プログラムの起動/初期化動作（「実行可能ファイル」のデータ形式、そこからのコード/データのロード方法、DLLの動作方法...）
これらに対する答えは次のとおりです。
- 言語固有（したがって、C ABI、C++ ABI、Fortran ABI、Pascal ABI、... Javaバイトコードの仕様は、実際のハードウェアではなく「仮想」プロセッサを対象としていますが、ABI）、
- オペレーティングシステム固有（同じハードウェア上のMS WindowsとLinuxは異なるABIを使用します）、
- ハードウェア/ CPU固有（ARMとx86 ABIは異なります）。
- （長い）時間をかけて進化する（既存のABIは、たとえば、新しいCPU機能を利用できるように、しばしば更新/改訂されていますx86 SSEレジスタをアプリで使用する方法を指定することはもちろん、CPUhadこれらのregしたがって、既存のABIを明確にする必要があります）。
何らかの種類のこの標準化がなければ、異なるコンパイラーによって作成された（マシン）コードは、同じ種類のライブラリーを使用できません（ライブラリーコードが関数の引数またはデータ構造が渡されることをどのように予測するのでしょうか？）。
すべてのプラットフォーム（特定のハードウェア、オペレーティングシステムソフトウェア、特定のプログラミング言語で記述されたコードの組み合わせ/特定のコンパイラでコンパイルされたもの）ABIのセット全体を定義して、相互運用可能にします。この分野の用語は明確ではありません。「ABI」について話すこともあれば、「プラットフォームサプリメント」と呼ばれることもあります。または、プログラミング言語に言及して、たとえば「C++ ABI」。覚えておいて、そのようなものはありません。
質問でリンクしたドキュメントは、すべてこの特定の例です（言語/オペレーティングシステム/ハードウェア固有のABI）。
特定のプラットフォーム上であっても、1つだけABI（セット）を持つ必要はありませんパフォーマンス/小さいコード/メモリ使用量の向上/ ...-プログラムによって異なります）およびシステム設計者は通常、柔軟で許容されるようにします。
たとえば、32ビットMicrosoft Windowsには、関数呼び出し規約パーツ用の多数のABI（fastcall、stdcall、Pascalなど）があります。
とにかく、 "ABI"（ "関連"サイドバーの下のリンクを含む）の一般的なstackoverflow検索は、この質問の調査に非常に多くのリードを与えるので、この時点で私の答えを閉じます。
ARMのOSカーネルポートが使用される場合、ARM ABIを参照する必要があります。
EABIは、プロセッサがブートして中間カーネルなしでアプリケーションをロードするときです。 （DOSが登場したとき、以前のようなものがROM-BASICでした）、i。 e。ファームウェア自体は独立したアプリケーションであり、ボード固有のモニターなどはありません。
最初のリンクは、ARM ABIのプロシージャ呼び出しに関連する詳細なサブパートです。プログラマーのモデルがARM CPUの各バージョンで進むにつれて、そのようなトピックは重要であり、ABIによってカバーされています。
2番目のリンクは、OSベンダーブランドSCOによって指定されたELFと呼ばれるコンパイラーによって生成されたオブジェクトファイルのバイナリ形式の仕様に関するものです。多分SCOはUnixとLinuxの独自のフレーバーを作っているサンタクルス組織ですが、その話は質問から逸脱しています。腕。
ARMのビルドツールチェーンの実装の詳細に直接関係する場合を除き、EABIはほとんど心配する必要はありません。また、そのようなツールチェーンのOS固有の側面を考慮する場合を除きますARM ABIも心配する必要はありません。