再配置(コンピューティング)

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

再配置は、プログラムの位置に依存するコードとデータにロードアドレスを割り当て、割り当てられたアドレスを反映するようにコードとデータを調整するプロセスです。[1] [2]マルチプロセスシステムが登場する前、そして今でも多くの組み込みシステムでは、オブジェクトのアドレスは既知の場所から始まり、多くの場合ゼロでした。マルチプロセッシングシステムはプログラムを動的にリンクして切り替えるため、位置に依存しないコードを使用してオブジェクトを再配置できるようにする必要がありました。リンカは通常、シンボル解決、つまりファイルとライブラリを検索してシンボリック参照またはライブラリの名前を置き換えるプロセスと組み合わせて再配置を実行しますプログラムを実行する前に 、メモリ内の実際に使用可能なアドレスを使用します。

再配置は通常、リンク時にリンカーによって実行されますが、ロード時に再配置ローダーによって実行されることも実行時に実行中のプログラム自体によって実行されることもあります。一部のアーキテクチャでは、再配置を完全に回避しています。たとえば、すべてのコンパイルユニットが個別のセグメントにロードされるセグメント化されたアーキテクチャ。

セグメンテーション

オブジェクトファイルは、さまざまなメモリセグメントタイプにセグメント化されています。セグメントの例には、コードセグメント(.text)初期化されたデータセグメント(.data)、初期化されていないデータセグメント(.bss)などがあります。[説明が必要]

再配置テーブル

再配置テーブルは、トランスレータ(コンパイラまたはアセンブラ)によって作成され、オブジェクトまたは実行可能ファイルに格納されているポインタのリストです。テーブルの各エントリ、つまり「fixup」は、オブジェクトコード内の絶対アドレスへのポインタであり、ローダーがプログラムを再配置して正しい場所を参照するようにするときに変更する必要があります。フィックスアップは、プログラムを完全なユニットとして再配置することをサポートするように設計されています。場合によっては、テーブル内の各フィックスアップ自体がゼロのベースアドレスを基準にしているため、ローダーがテーブル内を移動するときにフィックスアップ自体を変更する必要があります。[2]

一部のアーキテクチャでは、特定の境界(セグメント境界など)を越える、または単語境界に位置合わせされていない修正は違法であり、リンカーによってエラーとしてフラグが付けられます。[3]

DOSおよび16ビットWindows

DOS実行可能ファイルEXE )内のコードまたはデータを指すFarポインターセグメント:offsetを持つ32ビットポインター、DOSプログラムで使用可能な20ビット640 KBメモリスペースのアドレス指定に使用)には、絶対セグメントがありません。コード/データの実際のアドレスは、プログラムがメモリ内のどこにロードされているかによって異なり、プログラムがロードされるまでこれはわかりません。

代わりに、セグメントはDOSEXEファイルの相対値です。実行可能ファイルがメモリにロードされたら、これらのセグメントを修正する必要があります。EXEローダーは、再配置テーブルを使用して、調整が必要なセグメントを検索します。

32ビットWindows

32ビットWindowsオペレーティングシステムでは、EXEファイルの再配置テーブルを提供する必要はありません。EXEファイルは仮想アドレス空間にロードされる最初のイメージであり、優先ベースアドレスにロードされるためです。

DLLと、 Windows Vistaで導入されたエクスプロイト緩和手法であるアドレス空間配置のランダム化(ASLR)を選択するEXEの両方で、バイナリが実行される前に動的に移動される可能性があるため、テーブルの再配置が再び必須になります。それでも、仮想アドレス空間に最初にロードされるものです。

64ビットWindows

Windows Vista以降でネイティブ64ビットバイナリを実行する場合、ASLRは必須[要出典]であるため、コンパイラは再配置セクションを省略できません。

Unixライクなシステム

ほとんどのUnixライクなシステムで使用されているExecutableand Linkable Format(ELF)実行可能形式と共有ライブラリ形式を使用すると、いくつかのタイプの再配置を定義できます。[4]

移転手続き

リンカは、オブジェクトファイル内のセグメント情報と再配置テーブルを読み取り、次の方法で再配置を実行します。

  • 共通タイプのすべてのセグメントをそのタイプの単一セグメントにマージします
  • 各セクションと各シンボルに一意の実行時アドレスを割り当て、すべてのコード(関数)とデータ(グローバル変数)に一意の実行時アドレスを割り当てます[説明が必要]
  • 再配置テーブルを参照して変更する[なぜですか?]シンボルは、正しい[説明が必要]実行時アドレスを指すようにします。

次の例では、 DonaldKnuthMIXアーキテクチャとMIXALアセンブリ言語を使用しています。詳細は変更されますが、原則はどのアーキテクチャでも同じです。

再配置example.tif
  • (A)プログラムSUBRは、マシンコードとアセンブラの両方として表示されるオブジェクトファイル(B)を生成するようにコンパイルされます。コンパイラーは、コンパイルされたコードを任意の場所(多くの場合、図のように場所1)で開始できます。ロケーション13には、ロケーション5のステートメントSTへのジャンプ命令のマシンコードが含まれています。
  • (C)SUBRが後で他のコードとリンクされる場合、1以外の場所に格納される可能性があります。この例では、リンカーはSUBRを位置120に配置します。ジャンプ命令のアドレス(現在は位置133)を再配置する必要があります。ステートメントSTのコードの新しい場所を指すようになりました。現在は125です。[命令に示されている161は、125のMIXマシンコード表現です]。
  • (D)プログラムを実行するためにメモリにロードすると、リンカによって割り当てられた場所以外の場所にプログラムがロードされる場合があります。この例は、現在位置300にあるSUBRを示しています。ジャンプ命令のアドレス(現在313)は、 ST 305の更新された位置を指すように再配置する必要があります。[ 449は305のMIXマシン表現です]。

も参照してください

参考文献

  1. ^ 「オブジェクトコードのタイプ」。iRMX 86アプリケーションローダーリファレンスマニュアル (PDF)インテルpp。1-2–1-3。2020-01-11のオリジナルからアーカイブ (PDF)2020年1月11日取得[…]絶対コード、および絶対オブジェクトモジュールは、メモリ内の特定の場所でのみ実行されるようにLOC86によって処理されたコードです。ローダーは、絶対オブジェクトモジュールを、モジュールが占有する必要のある特定の場所にのみロードします位置に依存しないコード(一般にPICと呼ばれます)PICは任意のメモリ位置にロードできるという点で、絶対コードとは異なります。絶対コードに対するPICの利点は、PICが特定のメモリブロックを予約する必要がないことです。ローダーがPICをロードすると、呼び出し元のタスクのジョブのプールからiRMX 86メモリセグメントを取得し、PICをセグメントにロードします。PICに関する制限は、セグメンテーションのPL / M-86 COMPACTモデル[…]のように、これらのセグメントのベースアドレス、したがってセグメント自体を許可するのではなく、1つのコードセグメントと1つのデータセグメントのみを持つことができることです。 、動的に変化します。これは、PICプログラムの長さが必然的に64Kバイト未満であることを意味します。PICコードは、LINK86のBIND制御を使用して生成できます。ロード時に配置可能なコード(一般にLTLコードと呼ばれる)は、オブジェクトコードの3番目の形式です。LTLコードはメモリ内のどこにでもロードできるという点でPICに似ています。ただし、LTLコードをロードする場合、ローダーはポインターのベース部分を変更して、ポインターがマイクロプロセッサーのレジスターの初期内容から独立するようにします。この修正(ベースアドレスの調整)により、LTLコードは、複数のコードセグメントまたは複数のデータセグメントを持つタスクで使用できます。これは、LTLプログラムの長さが64Kバイトを超える可能性があることを意味します。FORTRAN86およびPascal86は、短いプログラムの場合でも、LTLコードを自動的に生成します。LTLコードは、LINK86のBIND制御を使用して生成できます。[…]
  2. ^ a b Levine、John R.(2000)[1999年10月]。「第1章:リンクとロードおよび第3章:オブジェクトファイル」。リンカーとローダーソフトウェア工学とプログラミングのモーガンカウフマンシリーズ(1版)。米国サンフランシスコ:モーガンカウフマンp。5. ISBN 1-55860-496-0OCLC42413382 _ 2012年12月5日にオリジナルからアーカイブされました2020年1月12日取得コード:[1] [2]エラッタ:[3]
  3. ^ Borland(1999-09-01)[1998-07-02]。「Borlandの記事#15961:「FixupOverflow」メッセージへの対処」community.borland.com技術情報データベース-製品:Borland C ++ 3.1。TI961C.txt#15961。2008年7月7日にオリジナルからアーカイブされました2007年1月15日取得
  4. ^ 「ExecutableandLinkable Format(ELF)」(PDF)skyfree.orgツールインターフェイス規格(TIS)ポータブルフォーマット仕様、バージョン1.1。2019-12-24のオリジナルからアーカイブ(PDF)2018年10月1日取得

さらに読む