実行可能かつリンク可能な形式

コンピューティングの分野では、実行可能およびリンク可能形式 [2] (ELF、以前は拡張リンク形式と呼ばれていました) は、実行可能ファイル、オブジェクトコード、共有ライブラリ、コアダンプの共通の標準ファイル形式です。最初は System V Release 4 (SVR4) と呼ばれる Unix オペレーティングシステムバージョンのアプリケーションバイナリインターフェイス (ABI) の仕様で公開され、[ 3 ^]後にツールインターフェイス標準で公開され、Unixシステムのさまざまなベンダーの間ですぐ^{に受け入れ}られました。1999 年には、86open プロジェクトによってx86プロセッサ上のUnix およびUnix 系システムの標準バイナリファイル形式として選ばれました。

ELF 形式は、設計上、柔軟性、拡張性、クロスプラットフォーム性を備えています。たとえば、さまざまなエンディアンやアドレス サイズをサポートしているため、特定のCPUや命令セット アーキテクチャが排除されることはありません。このため、さまざまなハードウェアプラットフォーム上のさまざまなオペレーティング システムで採用されています。

各 ELF ファイルは、1 つの ELF ヘッダーとそれに続くファイル データで構成されます。データには次のものが含まれます。

• 0個以上のメモリセグメントを記述するプログラムヘッダーテーブル
• 0 個以上のセクションを記述するセクション ヘッダー テーブル
• プログラムヘッダーテーブルまたはセクションヘッダーテーブルのエントリによって参照されるデータ

セグメントにはファイルの実行時に必要な情報が含まれており、セクションにはリンクと再配置のための重要なデータが含まれています。ファイル全体の任意のバイトは最大 1 つのセクションによって所有され、どのセクションにも所有されない孤立バイトが発生する可能性があります。

ELF ヘッダーは、 32 ビット アドレスを使用するか64 ビットアドレスを使用するかを定義します。ヘッダーには、この設定によって影響を受け、それに続く他のフィールドをオフセットする 3 つのフィールドが含まれます。ELF ヘッダーの長さは、32 ビット バイナリの場合は 52 バイト、64 ビット バイナリの場合は 64 バイトです。

プログラム ヘッダー テーブルは、プロセス イメージの作成方法をシステムに指示します。これはファイル オフセットe_phoffにあり、各エントリのサイズがe_phentsizeであるe_phnumエントリで構成されています。32ビットELF と64 ビットELFではレイアウトが若干異なります。これは、アライメント上の理由からp_flagsが別の構造体の場所にあるためです。各エントリは次のように構成されます。

• readelfは、1 つ以上の ELF ファイルに関する情報を表示する Unix バイナリ ユーティリティです。フリー ソフトウェア実装はGNU Binutilsによって提供されています。
• elfutils純粋にLinux向けのGNU Binutilsの代替ツールを提供します。 ^[10]
• elfdumpは、ELF ファイル内の ELF 情報を表示するためのコマンドであり、Solaris およびFreeBSDで使用できます。
• objdumpELF ファイルやその他のオブジェクト形式に関する幅広い情報を提供します。ELFデータを構造化するために、バックエンドとしてバイナリ ファイル記述子ライブラリをobjdump使用します。
• Unixfileユーティリティは、再配置可能、実行可能、または共有オブジェクト ファイル内のコードが対象としている命令セット アーキテクチャや、ELFコア ダンプが生成された命令セット アーキテクチャなど、ELF ファイルに関するいくつかの情報を表示できます。

ELF 形式は、さまざまな環境で古い実行形式に取って代わりました。Unix系オペレーティング システムでは、 a.out 形式とCOFF形式に取って代わりました。

• リナックス
• ソラリス/イルモス
• アイリックス
• フリーBSD ^[11]
• ネットBSD
• オープンBSD
• 酸化還元
• ドラゴンフライBSD
• 音節
• HP-UX ( SOM を引き続き使用する 32 ビット PA-RISC プログラムを除く)
• QNXニュートリノ
• ミニックス^[12]

ELF は、次のような Unix 以外のオペレーティング システムでも採用されています。

• OpenVMSのItanium版とamd64版^[13]
• x86ベースのコンピュータ用のBeOSリビジョン 4 以降( Portable Executable形式に代わるものです。PowerPCバージョンではPreferred Executable 形式のままです)
• Haiku、BeOS のオープンソース再実装
• RISC OS ^[14]
• Stratus VOS、PA-RISC および x86 バージョン
• スカイOS
• フクシアOS
• Z/TPF
• HPEノンストップOS ^[15]
• デオス

Microsoft WindowsもELF形式を使用していますが、これはWindows Subsystem for Linux互換システムのみに使用されています。^[16]

一部のゲームコンソールでも ELF が使用されています。

• プレイステーション・ポータブル、^[17]プレイステーション・ヴィータ、プレイステーション、プレイステーション2、プレイステーション3、プレイステーション4、プレイステーション5
• GP2X
• ドリームキャスト
• ゲームキューブ
• ニンテンドー64
• ウィイ
• WiiU について

ELF を使用する PowerPC 上で実行されるその他の (オペレーティング) システム:

• AmigaOS 4 では、ELF 実行ファイルが、PPC プロセッサ拡張カードを搭載した Amiga で使用されていた以前のExtended Hunk Format (EHF) に代わるものです。
• モルフォOS
• アロス
• Café OS (Wii U で動作するオペレーティングシステム)

携帯電話やモバイル デバイスの一部のオペレーティング システムでは ELF が使用されています。

• Symbian OS v9はELFファイル形式をベースにしたE32Image ^{[18]形式を使用します。}
• たとえば、Sony Ericsson の W800i、W610、W300 など。
• Siemens、SGOLD および SGOLD2 プラットフォーム: Siemens C65 から S75 および BenQ-Siemens E71/EL71。
• たとえば、Motorola の E398、SLVR L7、v360、v3i (およびパッチが適用されたすべての LTE2 電話)。
• たとえば、Samsung Wave S8500 などの Bada です。
• Maemo または Meego OS を実行する Nokia の携帯電話またはタブレット (例: Nokia N900)。
• Androidは、Java Native InterfaceにELF .so（共有オブジェクト^[19] ）ライブラリを使用します。^{[要出典] Android 5.0 "Lollipop"以降のデフォルトである}Android Runtime （ART）では、すべてのアプリケーションはインストール時にネイティブELFバイナリにコンパイルされます。^[20]また、TermuxなどのパッケージマネージャーからネイティブLinuxソフトウェアを使用することも、リポジトリで利用可能なClangまたはGCCを介してソースからコンパイルすることもできます。

一部の携帯電話では、メインファームウェアにアセンブリコードを追加するパッチを使用することでELFファイルを実行できます。これは、アンダーグラウンドの改造文化ではELFPackと呼ばれる機能です。ELFファイル形式は、Atmel AVR（8ビット）、AVR32 ^[21] 、およびTexas Instruments MSP430マイクロコントローラアーキテクチャでも使用されています。Open Firmwareの実装の中には、ELFファイルを読み込むことができるものもあります。最も有名なのは、Appleの実装で、同社が製造したほぼすべてのPowerPCマシンで使用されています。

• Solanaはオンチェーンプログラム（スマートコントラクト）にELF形式を使用しています。プラットフォームはBPF（Berkeley Packet Filter）バイトコードにコンパイルされたELFファイルを処理し、共有オブジェクトとして展開され、Solanaのランタイム環境で実行されます。BPFローダーは、プログラムの展開中にこれらのELFファイルを検証して処理します。^[22]

86openは、一般的なPC互換のx86アーキテクチャ上のUnixおよびUnix系オペレーティングシステム用の共通バイナリファイル形式について合意を形成し、ソフトウェア開発者にアーキテクチャへの移植を促すプロジェクトでした。^[23]当初のアイデアは、Single UNIX仕様の前身であるSpec 1170の小さなサブセットとGNU Cライブラリ（glibc）を標準化して、変更されていないバイナリをx86 Unix系オペレーティングシステムで実行できるようにすることでした。このプロジェクトは当初「Spec 150」と呼ばれていました。

最終的に選択されたフォーマットは ELF、具体的には ELF の Linux 実装であり、関係するすべてのベンダーとオペレーティング システムによってサポートされる事実上の標準であることが判明しました。

このグループは 1997 年に電子メールによる議論を開始し、1997 年 8 月 22 日にサンタクルーズ事業所のオフィスで初めて会合を開きました。

運営委員会のメンバーは、Marc Ewing、Dion Johnson、Evan Leibovitch、Bruce Perens、Andrew Roach、Bryan Wayne Sparks、および Linus Torvalds でした。プロジェクトの他のメンバーは、Keith Bostic、Chuck Cranor、Michael Davidson、Chris G. Demetriou、Ulrich Drepper、Don Dugger、Steve Ginzburg、Jon "maddog" Hall、Ron Holt、Jordan Hubbard、Dave Jensen、Kean Johnston、Andrew Josey、Robert Lipe、Bela Lubkin、Tim Marsland、Greg Page、Ronald Joe Record、Tim Ruckle、Joel Silverstein、Chia-pi Tien、および Erik Troan でした。参加したオペレーティング システムと企業は、BeOS、BSDI、FreeBSD、Intel、Linux、NetBSD、SCO、および SunSoft でした。

プロジェクトは進展し、1998年半ばにSCOはOpenServer、UnixWare、Solaris上でLinuxバイナリを実行できるオープンソースの互換性レイヤーであるlxrunの開発を開始しました。SCOは1999年3月のLinuxWorldでlxrunの公式サポートを発表しました。サンマイクロシステムズは1999年初頭にSolaris用のlxrunの公式サポートを開始し、^[24]後にSolaris Containers for Linux Applicationsを介してLinuxバイナリ形式の統合サポートに移行しました。

BSD は長い間 Linux バイナリをサポートしており (互換性レイヤーを通じて)、主要な x86 Unix ベンダーもこの形式のサポートを追加していたため、プロジェクトは Linux ELF が業界が選択した形式であると決定し、1999 年 7 月 25 日に「解散を宣言」しました。^[25]

FatELFは、ファットバイナリ機能を追加するELFバイナリ形式の拡張です。^[26] Linuxやその他のUnix系オペレーティングシステムを対象としています。CPUアーキテクチャの抽象化（バイトオーダー、ワードサイズ、CPU命令セットなど）に加えて、複数のカーネルABIバージョンをサポートするバイナリなど、ソフトウェアプラットフォームの抽象化の潜在的な利点があります。2021年現在^{[アップデート]}、FatELFはメインラインのLinuxカーネルに統合されていません。^{[27] [28] [29]}

• アプリケーションバイナリインターフェース
• 実行ファイル形式の比較
• DWARF – デバッグデータ用のフォーマット
• Intel バイナリ互換性標準
• ポータブル実行可能ファイル – Windowsで使用される形式
• vDSO – 仮想 DSO
• 位置独立コード

^[1]