オブジェクトファイル

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ

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

オブジェクトコード自体に加えて、オブジェクトファイルには、リンクまたはデバッグに使用されるメタデータが含まれる場合があります。これには、異なるモジュール間のシンボリック相互参照を解決するための情報、再配置情報、スタック巻き戻し情報、コメント、プログラムシンボル、デバッグまたはプロファイリング情報が含まれます。その他のメタデータには、コンパイルの日付と時刻、コンパイラの名前とバージョン、およびその他の識別情報が含まれる場合があります。

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

プログラマーによって書かれたソースプログラムを代数表記に似た言語に翻訳することによって機械によって生成される機械語プログラムの自動プログラミングの用語。[1]

コンピュータープログラマーは、コンパイラーまたはアセンブラーを使用してオブジェクトコードを生成します。たとえば、Linuxでは、GNUコンパイラコレクションコンパイラは、 ELF形式を使用する.o拡張子のファイルを生成します。Windowsでコンパイルすると、 COFF形式を使用する.obj拡張子のファイルが生成されます。次に、リンカを使用して、オブジェクトコードを1つの実行可能プログラムまたはライブラリに結合し、必要に応じてプリコンパイルされたシステムライブラリを取り込みます。

オブジェクトファイル形式

多くの異なるオブジェクトファイル形式があります。もともと各タイプのコンピュータには独自のフォーマットがありましたが、Unixやその他のポータブル オペレーティングシステムの出現により、 ELFCOFFなどの一部のフォーマットが定義され、さまざまな種類のシステムで使用されるようになりました。リンカの入力と出力の両方として、したがってライブラリ実行可能ファイルの形式として同じ形式を使用することができます。[2] :p.16 一部の形式には、プログラムのロード時にオペレーティングシステムによって選択された正しいプロセッサを使用して、さまざまなプロセッサのマシンコードを含めることができます。[3]

一部のシステムでは、直接実行可能な形式とリンカによる処理が必要な形式を区別しています。たとえば、OS / 360以降では、最初の形式をロードモジュールと呼び、2番目の形式をオブジェクトモジュールと呼びます。この場合、ファイルの形式はまったく異なります。

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

絶対オブジェクトファイル

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

セグメンテーション

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

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

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

デバッグ情報は、 COFFのようにオブジェクトファイル形式の不可欠な部分であるか、スタブDWARFなどのいくつかのオブジェクト形式で使用できる半独立形式のいずれかです。

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

参考文献

  1. ^ Wrubel、マーシャルH.(1959)。デジタルコンピュータのためのプログラミングの入門書ニューヨーク:マグロウヒル。p。222 2020年7月31日取得
  2. ^ IBM Corporation(1973)。IBM OSリンケージエディターおよびローダー(PDF)2012年8月6日取得
  3. ^ 「FatELF:Linux用のユニバーサルバイナリ」2020年8月2日取得
  4. ^ ワイルズ、マイク; フェリックス、アンドレ。MCM6830L7 MIKBUG / MINIBUG ROM(PDF)モトローラセミコンダクタープロダクツ株式会社 2020年7月31日取得
  5. ^ ゴドセ、DA; ゴドセ、AP(2008)。マイクロプロセッサ-I(初版)。プネ:技術出版物。pp。3–15。ISBN 978-81-8431-355-0
  6. ^ Mauerer、Wolfgang(2010)。プロフェッショナルLinuxカーネルアーキテクチャジョン・ワイリー&サンズ。p。付録E:ELFバイナリ形式。ISBN 978-0-470-34343-22020年8月1日取得
  7. ^ Irvine、Kip R.(1993)、IBM-PCのアセンブリ言語(第2版)、ニューヨーク:Macmillan、ISBN 0-02-359651-1

さらに読む