オブジェクトファイル

オブジェクトファイルとは、コンパイルまたはアセンブリ プロセス中にコンパイラまたはアセンブラによってソース コードから生成されたマシン コードまたはバイトコード、およびその他のデータとメタデータを含むファイルです。生成されるマシン コードはオブジェクト コードと呼ばれます。

オブジェクト コードは通常は再配置可能であり、直接実行可能ではありません。オブジェクト ファイルにはさまざまな形式があり、同じマシン コードを異なるオブジェクト ファイル形式でパッケージ化できます。オブジェクト ファイルは共有ライブラリのように機能する場合もあります。

オブジェクト ファイルに含まれるメタデータは、リンクやデバッグに使用できます。メタデータには、異なるモジュール間のシンボリック相互参照を解決するための情報、再配置情報、スタック アンワインド情報、コメント、プログラムシンボル、デバッグまたはプロファイリング情報などが含まれます。その他のメタデータには、コンパイルの日時、コンパイラ名とバージョン、その他の識別情報が含まれる場合があります。

「オブジェクト プログラム」という用語は、少なくとも 1950 年代にまで遡ります。

自動プログラミングにおける用語で、プログラマーが代数記法に似た言語で書いたソースプログラムを機械が翻訳して生成する機械語プログラムを指す。^[1]

リンカーは、必要に応じて事前コンパイルされたシステム ライブラリを取り込んで、オブジェクト コードを 1 つの実行可能プログラムまたはライブラリに結合するために使用されます。

オブジェクト ファイル形式にはさまざまなものがあります。もともとはコンピュータの種類ごとに独自の形式がありましたが、Unixやその他のポータブル オペレーティング システムの登場により、 ELFやCOFFなどの形式が定義され、さまざまな種類のシステムで使用されるようになりました。

一部のシステムでは、直接実行可能な形式とリンカーによる処理を必要とする形式を区別しています。たとえば、OS/360と後継システムでは、最初の形式をロードモジュール、2番目の形式をオブジェクトモジュールと呼んでいます。この場合、ファイルの形式はまったく異なります。^[2] DOSとWindowsでは、実行可能ファイルとオブジェクトファイルのファイル形式も異なり、たとえば、 32ビットおよび64ビットWindowsでは実行可能ファイルはPortable Executable、オブジェクトファイルはCOFFです。

UnixおよびUnix系システムは、オリジナルのa.out形式から始まり、実行ファイルとオブジェクトファイルに同じ形式を使用しています。一部の形式には、異なるプロセッサ用のマシンコードを含めることができ、プログラムがロードされたときにオペレーティングシステムによって適切なものが選択されます。^{[3] [4]}

オブジェクト ファイル形式の設計および選択は、システム設計全体の重要な部分です。これは、リンカーのパフォーマンスに影響し、プログラム開発中のプログラマーのターンアラウンドに影響します。形式が実行可能ファイルに使用される場合、設計はプログラムの実行開始にかかる時間にも影響し、ユーザーに対する応答性にも影響します。

GNUプロジェクトのバイナリ ファイル記述子ライブラリ(BFD ライブラリ) は、さまざまな形式のオブジェクト ファイルを操作するための 共通A​​PI を提供します。

初期のコンピュータや小型マイクロコンピュータの多くは、絶対オブジェクト形式のみをサポートしています。プログラムは再配置可能ではありません。特定の定義済みアドレスで実行するために、アセンブルまたはコンパイルする必要があります。ファイルには再配置情報やリンク情報は含まれていません。これらのファイルは、読み取り/書き込みメモリにロードすることも、読み取り専用メモリに保存することもできます。たとえば、モトローラ 6800 MIKBUGモニタには、紙テープから絶対オブジェクト ファイル ( SREC 形式)を読み取るルーチンが含まれています。^[5] DOS COM ファイルは、より最近の絶対オブジェクト ファイルの例です。^[6]

ほとんどのオブジェクト ファイル形式は、データの個別のセクションとして構造化されており、各セクションには特定のタイプのデータが含まれています。これらのセクションは、以前は一般的なメモリ管理形式であった「メモリ セグメント」という用語にちなんで「セグメント」と呼ばれています。プログラムがローダーによってメモリにロードされると、ローダーはプログラムにさまざまなメモリ領域を割り当てます。これらの領域の一部はオブジェクト ファイルのセクションに対応しているため、通常は同じ名前で知られています。スタックなどの他の領域は、実行時にのみ存在します。場合によっては、実際のメモリ アドレスを指定するために、ローダー (またはリンカー) によって再配置が行われます。ただし、多くのプログラムまたはアーキテクチャでは、メモリ管理ユニットまたは位置独立コードによって処理されるため、再配置は必要ありません。一部のシステムでは、オブジェクト ファイルのセグメントをメモリにコピー (ページング) して実行することができ、それ以上の処理は必要ありません。これらのシステムでは、これは遅延して実行される可能性があります。つまり、セグメントが実行中に参照される場合にのみ、たとえばオブジェクト ファイルによってバックアップされたメモリ マップ ファイルを介して実行されます。

一般的なオブジェクトファイル形式でサポートされるデータの種類: ^[7]

• ヘッダー（説明および制御情報）
• コード セグメント(「テキスト セグメント」、実行可能コード)
• データセグメント（初期化された静的変数）
• 読み取り専用データセグメント ( rodata、初期化された静的定数)
• BSS セグメント(初期化されていない静的データ、変数と定数の両方)
• リンクのための外部定義と参照
• 移転情報
• 動的リンク情報
• デバッグ情報

異なるオブジェクトファイル内のセグメントは、セグメントが定義されたときに指定された規則に従ってリンカーによって結合されることがあります。オブジェクトファイル間で共有されるセグメントには規則があります。たとえば、DOSには、特別なセグメントの名前と、それらが結合できるかどうかを指定するさまざまなメモリモデルがあります。^[8]

デバッグ情報のデバッグ データ形式は、COFFのようにオブジェクト ファイル形式の不可欠な部分である場合もあれば、スタブやDWARFなどの複数のオブジェクト形式で使用できる半独立形式である場合もあります。

• OS/360 オブジェクト ファイル形式
• Intel 16 進オブジェクト ファイル形式(通常はファイル拡張子 .HEX ですが、場合によっては .OBJ の場合もあります)
• オブジェクト モジュール フォーマット (ICL) (ICL VME の OMF)
• オブジェクト モジュール フォーマット (Intel) (Intel 8080/8085 の場合は OMF、Intel 8086 の場合は OBJ)
• マッハO

• Levine, John R. (2000) [1999 年 10 月]。「第 3 章: オブジェクト ファイル」。リンカーとローダー。Morgan Kaufmann シリーズ ソフトウェア エンジニアリングおよびプログラミング (第 1 版)。米国カリフォルニア州サンフランシスコ: Morgan Kaufmann。p . 256。ISBN 1-55860-496-0. OCLC  42413382. 2013年1月25日時点のオリジナルよりアーカイブ。2020年1月12日閲覧。コード: [1][2] エラッタ: [3]
• Microsoft OBJ ファイル形式。Microsoft 、製品サポート サービス。アプリケーション ノート SS0288。2017 年 9 月 9 日にオリジナルからアーカイブされました。2017年 8 月 21 日に取得。
• Elliott, John C. (2002). 「Microsoft REL ファイル形式」. seasip.info . 2023-11-25 にオリジナルからアーカイブ。2023-11-25に取得。(注: Digital Research でも使用されている、再配置可能なオブジェクト用の Microsoft REL ファイル形式の説明。)
• Elliott, John C. (2012-06-05) [2000-01-02]. 「PRL ファイル形式」. seasip.info . 2020-01-26 にオリジナルからアーカイブ。2020-01-26に取得。[4]
• Fraser, Christopher "Chris" W. ; Hanson, David R. (1982 年 4 月 - 5 月) [1981-09-09, 1981-11-02]. 「マシンに依存しないリンカー」(PDF) .ソフトウェア: 実践と経験 [d] . 12 (4). アリゾナ大学、アリゾナ州ツーソン、米国: John Wiley & Sons, Ltd. : 351 - 366. doi :10.1002/spe.4380120407. ISSN  0038-0644. 2023-11-28 にオリジナルからアーカイブ(PDF)されました。2023-11-28に取得。（16ページ）
• Montuelle, Jean; Willers, Ian (1979年9月25日～28日) [1978年10月]。スイス、ジュネーブのCERNで執筆。ユニバーサルオブジェクトモジュールフォーマット、CUFOMを使用したクロスソフトウェア。Euro IFIP、ロンドン、英国。CERN-DD/78/20。2023年11月28日閲覧。(1+23ページ)
• マイクロプロセッサ オブジェクト モジュール用ユニバーサル フォーマット、MUFOM (ドラフト ドキュメント)、IEEEワーキング グループ、P695lD2
• Montuelle, Jean; Willers, Ian (1982年9月). 「編集者への手紙」.ソフトウェア: 実践と経験 [d] . 12 (9). CERN、ジュネーブ、スイス: John Wiley & Sons, Ltd. : 883–884 [884]. doi : 10.1002/spe.4380120909 . ISSN  0038-0644.(1 ページ) (注: IEEE 695 と CUFOM および MUFOM の歴史と関係について説明します。)
• IEEE 695-1990: オブジェクト モジュールのマイクロプロセッサ ユニバーサル フォーマットの IEEE 標準。IEEE。1990-02-05。doi : 10.1109 / IEEESTD.1990.101062。ISBN 978-0-7381-3028-6。(注: IEEE 695-1985 (1985-09-09) に代わるものです)。