移転（コンピューティング）

ソフトウェア開発において、再配置とは、プログラムの位置に依存するコードとデータにロードアドレスを割り当て、割り当てられたアドレスを反映するようにコードとデータを調整するプロセスです。 [ 1 ] [ 2 ]

リンカーは通常、シンボル解決と組み合わせて再配置を実行します。シンボル解決とは、プログラムを実行する前に、ファイルとライブラリを検索して、シンボル参照またはライブラリ名をメモリ内の実際に使用可能なアドレスに置き換えるプロセスです。

再配置は、通常、リンク時にリンカーによって実行されますが、再配置ローダーによってロード時に実行されたり、実行中のプログラム自体によって実行時に実行されたりすることもできます。

セグメンテーション

オブジェクトファイルは通常、様々なメモリセグメントまたはセクションタイプに分割されます。セグメントタイプの例としては、コードセグメント（.text）、初期化済みデータセグメント（.data）、未初期化データセグメント（.bss）、その他プログラマーが定義した共通セグメントや名前付き静的セグメントなどがあります。

再配置テーブル

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

一部のアーキテクチャでは、特定の境界（セグメント境界など）を越えるフィックスアップやワード境界に揃えられていないフィックスアップは不正であり、リンカーによってエラーとしてフラグが付けられます。[ 3 ]

DOS および 16 ビット Windows

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

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

ウィンドウズ

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

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

Windows実行ファイルはASLR互換としてマークできます。Windows 8以降では、互換としてマークされていないアプリケーションでもASLRを有効にする機能があります。[ 4 ]この環境で正常に動作させるには、コンパイラによって再配置セクションを省略することはできません。

Unix系システム

ほとんどのUnix系システムで使用されている実行可能およびリンク可能フォーマット（ELF）実行可能ファイルと共有ライブラリフォーマットでは、いくつかの種類の再配置を定義することができます。[ 5 ]：1–22

移転手続き

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

  • 共通タイプのすべてのセグメントをそのタイプの単一のセグメントに結合する
  • 各セグメントと各シンボルに重複しない実行時アドレスを割り当て、すべてのコード（関数）とデータ（グローバル変数）に一意の実行時アドレスを割り当てます。
  • 再配置テーブルを参照して、データおよびオブジェクト コード内のシンボル参照を変更し、割り当てられた実行時アドレスを指すようにします。

例

以下の例では、ドナルド・クヌースのMIXアーキテクチャとMIXALアセンブリ言語を使用しています。詳細は異なりますが、原則はどのアーキテクチャでも同じです。

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

代替案

一部のアーキテクチャでは、アドレスの割り当てを実行時に延期することで、再配置を完全に回避します。たとえば、ゼロ アドレス演算を実行するスタック マシンや、すべてのコンパイル ユニットが個別のセグメントにロードされるセグメント化されたアーキテクチャなどです。

参照

参考文献

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

さらに読む

「 https://en.wikipedia.org/w/index.php?title=Relocation_(computing)&oldid=1331282178#Offset」より取得