オブジェクトファイルとは、コンパイルまたはアセンブリ処理中にコンパイラまたはアセンブラによってソースコードから生成される、マシンコードまたはバイトコード、およびその他のデータやメタデータを含むファイルのことです。生成されるマシンコードはオブジェクトコードと呼ばれます。
オブジェクトコードは通常、再配置可能であり、直接実行可能ではありません。オブジェクトファイルにはさまざまな形式があり、同じマシンコードでも異なるオブジェクトファイル形式でパッケージ化できます。オブジェクトファイルは共有ライブラリのように機能することもあります。
オブジェクトファイルに含まれるメタデータは、リンクやデバッグに使用できます。これには、異なるモジュール間のシンボル相互参照を解決するための情報、再配置情報、スタックアンワインド情報、コメント、プログラムシンボル、デバッグ情報またはプロファイリング情報などが含まれます。その他のメタデータには、コンパイル日時、コンパイラ名とバージョン、その他の識別情報が含まれる場合があります。
「オブジェクトプログラム」という用語は、少なくとも1950年代から存在している。
自動プログラミングにおける用語で、代数記法に似た言語でプログラマが書いたソースプログラムを機械が翻訳して生成する機械語プログラムを指す。[ 1 ]
リンカーは、必要に応じてプリコンパイル済みのシステムライブラリを取り込みながら、オブジェクトコードを1つの実行可能プログラムまたはライブラリに結合するために使用されます。
オブジェクトファイル形式にはさまざまな種類があります。当初は、OS/360オブジェクトファイル形式のように、コンピュータの種類やサポートソフトウェアごとに独自の形式がありましたが、 Unixやその他のポータブルオペレーティングシステムの登場により、 COFF、ELF、Mach-Oなどの形式が定義され、さまざまな種類のシステムで使用されるようになりました。
システムによっては、直接実行可能な形式とリンカによる処理が必要な形式を区別しているものがあります。たとえば、OS/360 とその後継システムでは、前者をロードモジュール、後者をオブジェクトモジュールと呼んでいます。この場合、ファイルは全く異なる形式になります。[ 2 ] DOSとWindowsも、実行可能ファイルとオブジェクトファイルで異なるファイル形式を採用しており、32 ビット版と 64 ビット版の Windows では、実行可能ファイルにはPortable Executable 、オブジェクトファイルには COFF が使用されています。
Unix およびUnix ライクなシステムは、オリジナルのa.outフォーマットから始まり、実行可能ファイルとオブジェクトファイルに同じフォーマットを使用してきました。一部のフォーマットには、異なるプロセッサ用のマシン コードを含めることができ、プログラムがロードされるときにオペレーティングシステムによって適切なものが選択されます。[ 3 ] [ 4 ]
オブジェクトファイル形式の設計および選択は、システム全体の設計において重要な要素です。これはリンカのパフォーマンスに影響を与え、ひいてはプログラム開発中のプログラマーの作業効率に影響します。実行ファイルにこの形式が使用される場合、設計はプログラムの実行開始時間にも影響し、ユーザーの応答性にも影響します。
GNUプロジェクトのバイナリファイル記述子ライブラリ(BFDライブラリ)は、さまざまな形式のオブジェクトファイルを操作するための共通APIを提供します。
多くの初期のコンピュータ、あるいは小型マイクロコンピュータは、絶対オブジェクト形式のみをサポートしています。プログラムは再配置できません。特定の定義済みアドレスで実行するために、アセンブルまたはコンパイルする必要があります。ファイルには再配置情報やリンク情報は含まれていません。これらのファイルは読み書き可能なメモリにロードすることも、読み取り専用メモリに格納することもできます。たとえば、Motorola 6800 MIKBUGモニタには、紙テープから絶対オブジェクトファイル( SREC形式)を読み取るルーチンが含まれています。[ 5 ] DOS COMファイルは、絶対オブジェクトファイルのより最近の例です。[ 6 ]
ほとんどのオブジェクトファイル形式は、それぞれ特定の種類のデータを含む個別のデータセクションとして構成されています。これらのセクションは、以前は一般的なメモリ管理形式であった「メモリセグメント」という用語にちなんで「セグメント」と呼ばれています。プログラムがローダーによってメモリにロードされると、ローダーはプログラムにさまざまなメモリ領域を割り当てます。これらの領域の一部はオブジェクトファイルのセクションに対応しており、通常同じ名前で知られています。スタックなどの他の領域は、実行時にのみ存在します。場合によっては、ローダー(またはリンカー)によって再配置が行われ、実際のメモリ アドレスが指定されます。ただし、多くのプログラムやアーキテクチャでは、メモリ管理ユニットまたは位置独立コードによって処理されるため、再配置は不要です。一部のシステムでは、オブジェクトファイルのセグメントをメモリにコピー(ページング)して、それ以上の処理を必要とせずに実行できます。これらのシステムでは、これは遅延実行、つまり、たとえばオブジェクトファイルによってバックアップされたメモリ マップ ファイルを介して、実行中にセグメントが参照された場合にのみ実行される場合があります。
一般的なオブジェクトファイル形式でサポートされているデータの種類: [ 7 ]
異なるオブジェクトファイル内のセグメントは、セグメントが定義されたときに指定された規則に従ってリンカによって結合されることがあります。オブジェクトファイル間で共有されるセグメントには慣例が存在します。たとえば、DOSでは、特殊セグメントの名前と、それらを結合できるかどうかを指定するさまざまなメモリ モデルがあります。[ 8 ]
デバッグ情報のデバッグデータ形式は、 COFFのようにオブジェクトファイル形式に不可欠な部分である場合もあれば、 stabsやDWARFのように複数のオブジェクト形式で使用できる半独立形式である場合もある。
{{cite book}}: CS1 maint: 非推奨のアーカイブサービス (リンク)コード: [リンク削除済み]訂正:{{cite book}}: CS1メンテナンス: アーカイブサービスは非推奨になりました (リンク)