PE 形式
この仕様では、Windows ファミリのオペレーティング システムでの実行可能 (イメージ) ファイルとオブジェクト ファイルの構造について説明します。 これらのファイルは、それぞれ移植可能な実行可能ファイル (PE) とCommon Object File Format (COFF) ファイルと呼ばれています。
注意
このドキュメントは、Windows 用のツールとアプリケーションの開発を支援するために提供されていますが、すべての点で完全な仕様であるとは限りません。 Microsoft は、予告なしにこのドキュメントを変更する権利を留保します。
Microsoft 移植可能な実行可能ファイルおよび Common Object File Format 仕様のこのリビジョンは、この仕様の以前のすべてのリビジョンに置き換わります。
一般的な概念
このドキュメントでは、Microsoft Windows ファミリのオペレーティング システムの実行可能 (イメージ) ファイルとオブジェクト ファイルの構造を指定します。 これらのファイルは、それぞれ移植可能な実行可能ファイル (PE) とCommon Object File Format (COFF) ファイルと呼ばれています。 "移植可能な実行可能ファイル" という名前は、形式がアーキテクチャ固有ではないということを指しています。
次の表では、この仕様全体で使用される特定の概念について説明します。
| 名前 | Description |
|---|---|
| 属性証明書 |
検証可能ステートメントをイメージに関連付けるために使用される証明書。 さまざまな検証可能ステートメントをファイルに関連付けることができます。最も便利なものの 1 つは、イメージのメッセージ ダイジェストの想定される内容を示すソフトウェア製造元によるステートメントです。 メッセージ ダイジェストはチェックサムに似ていますが、偽造することは極めて困難です。 したがって、元のファイルと同じメッセージ ダイジェストを持つようにファイルを変更することは非常に困難です。 ステートメントでは、公開または秘密キー暗号化スキームを使用して、製造元によって作成されたものであることを検証できます。 このドキュメントでは、イメージ ファイルへの挿入を可能にすることのほか、属性証明書の詳細について説明します。 |
| 日付/時刻スタンプ |
PE または COFF ファイル内の複数の場所で異なる目的のために使用されるスタンプ。 ほとんどの場合、各スタンプの形式は、C ランタイム ライブラリの時刻関数で使用される形式と同じです。 例外については、「デバッグの種類」の IMAGE_DEBUG_TYPE_REPRO の説明を参照してください。 スタンプ値が 0 または 0xFFFFFFFF の場合、実際の意味のある日付/時刻スタンプを表していません。 |
| ファイル ポインター |
リンカー (オブジェクト ファイルの場合) またはローダー (イメージ ファイルの場合) によって処理される前の、ファイル自体の中にある項目の場所。 つまり、これはディスクに格納されているファイル内の位置です。 |
| リンカー |
Microsoft Visual Studio で提供されるリンカーへの参照。 |
| オブジェクト ファイル |
リンカーへの入力として提供されるファイル。 リンカーによってイメージ ファイルが生成され、その後ローダーによって入力として使用されます。 "オブジェクト ファイル" という用語は、必ずしもオブジェクト指向プログラミングとの関連を意味するわけではありません。 |
| 予約済み。0 である必要があります |
ジェネレーターの場合はフィールドの値を 0 にする必要があり、コンシューマーはフィールドを無視する必要があることを示すフィールドの説明。 |
| 相対仮想アドレス (RVA) |
イメージ ファイルでは、これはメモリに読み込まれた後の項目のアドレスであり、イメージ ファイルのベース アドレスはそこから引かれています。 アイテムの RVA は、ほとんどの場合、ディスク上のファイル内の位置 (ファイル ポインター) とは異なります。 オブジェクト ファイルでは、メモリの場所が割り当てられないため、RVA はあまり意味がありません。 この場合、RVA はセクション内のアドレスになります (この表の後半で説明します)。リンク時に後で再配置が適用されます。 単純にするために、コンパイラでは、各セクションの最初の RVA を 0 に設定する必要があります。 |
| section |
PE または COFF ファイル内のコードまたはデータの基本単位。 たとえば、オブジェクト ファイル内のすべてのコードを 1 つのセクション内で結合することも、(コンパイラの動作に応じて) 各関数が独自のセクションを占有することもできます。 セクションが多いほどファイルのオーバーヘッドが増えますが、リンカーがコード内でより選択的にリンクできるようになります。 セクションは、Intel 8086 アーキテクチャのセグメントに似ています。 セクション内のすべての生データを隣接して読み込む必要があります。 さらに、イメージ ファイルには、特別な目的を持ついくつかのセクション (.tls や .reloc など) を含めることができます。 |
| 仮想アドレス (VA) |
イメージ ファイルのベース アドレスが引かれない点を除けば、RVA と同じです。 このアドレスが VA と呼ばれるのは、物理メモリに関係なく、Windows によってプロセスごとに個別の VA 領域が作成されるためです。 ほぼすべての目的において、VA は単なるアドレスと見なす必要があります。 ローダーは指定の場所にイメージを読み込むとは限らないため、VA は RVA ほど予測可能ではありません。 |
概要
次の一覧では、Microsoft PE 実行可能ファイル形式について説明します。イメージ ヘッダーのベースが冒頭に記載されています。 MS-DOS 2.0 互換 EXE ヘッダーから PE ヘッダーの直前の未使用セクションまでのセクションは、MS-DOS 2.0 セクションであり、MS-DOS の互換性のためにのみ使用されます。
MS-DOS 2.0 互換 EXE ヘッダー
未使用
OEM 識別子
OEM 情報
PE ヘッダーへのオフセット
MS-DOS 2.0 スタブ プログラムと再配置テーブル
未使用
PE ヘッダー (8 バイト境界に配置)
セクション ヘッダー
イメージ ページ:
インポート情報
エクスポート情報
ベース再配置
リソース情報
次の一覧では、Microsoft COFF オブジェクト モジュール形式について説明します。
Microsoft COFF ヘッダー
セクション ヘッダー
生データ:
code
data
デバッグ情報
再配置
ファイル ヘッダー
PE ファイル ヘッダーは、Microsoft MS-DOS スタブ、PE 署名、COFF ファイル ヘッダー、およびオプションのヘッダーで構成されます。 COFF オブジェクト ファイル ヘッダーは、COFF ファイル ヘッダーとオプションのヘッダーで構成されます。 どちらの場合も、ファイル ヘッダーの直後にセクション ヘッダーが続きます。
MS-DOS スタブ (イメージのみ)
MS-DOS スタブは、MS-DOS で実行される有効なアプリケーションです。 EXE イメージの先頭に配置されます。 リンカーによって既定のスタブがここに配置されます。これにより、イメージが MS-DOS で実行されると、"This program cannot be run in DOS mode" (このプログラムは DOS モードで実行できません) というメッセージが出力されます。 ユーザーは、/STUB リンカー オプションを使用して別のスタブを指定できます。
0x3c の位置に、スタブには PE 署名へのファイル オフセットがあります。 この情報により、MS-DOS スタブがある場合でも、Windows はイメージ ファイルを適切に実行できます。 このファイル オフセットは、リンク時に 0x3c の位置に配置されます。
署名 (イメージのみ)
MS-DOS スタブの後、オフセット 0x3cで指定されたファイル オフセットに、PE 形式のイメージ ファイルとしてファイルを識別する 4 バイト署名が配置されます。 この署名は "PE\0\0" です (文字 "P" と "E" の後に 2 つの null バイトが続きます)。
COFF ファイル ヘッダー (オブジェクトとイメージ)
オブジェクト ファイルの先頭またはイメージ ファイルの署名の直後は、次の形式の標準の COFF ファイル ヘッダーです。 Windows ローダーでは、セクションの数が 96 に制限されることに注意してください。
| Offset | サイズ | フィールド | 説明 |
|---|---|---|---|
| 0 |
2 |
Machine |
ターゲット マシンの種類を識別する番号。 詳細については、「マシンの種類」を参照してください。 |
| 2 |
2 |
NumberOfSections |
セクションの数。 これは、ヘッダーのすぐ後に続くセクション テーブルのサイズを示します。 |
| 4 |
4 |
TimeDateStamp |
1970 年 1 月 1 日の 00:00 からの秒数の下位 32 ビット (C ランタイムの time_t 値)。これは、ファイルがいつ作成されたかを示します。 |
| 8 |
4 |
PointerToSymbolTable |
COFF シンボル テーブルのファイル オフセット。COFF シンボル テーブルが存在しない場合は 0。 COFF デバッグ情報は非推奨であるため、イメージの場合、この値は 0 にする必要があります。 |
| 12 |
4 |
NumberOfSymbols |
シンボル テーブル内のエントリの数。 このデータを使用すれば、シンボル テーブルのすぐ後に続く文字列テーブルを検索することができます。 COFF デバッグ情報は非推奨であるため、イメージの場合、この値は 0 にする必要があります。 |
| 16 |
2 |
SizeOfOptionalHeader |
オプションのヘッダーのサイズ。これは、実行可能ファイルでは必須ですが、オブジェクト ファイルには必要ありません。 オブジェクト ファイルの場合、この値は 0 とする必要があります。 ヘッダー形式の説明については、「オプションのヘッダー (イメージのみ)」を参照してください。 |
| 18 |
2 |
特性 |
ファイルの属性を示すフラグ。 特定のフラグ値については、「特性」を参照してください。 |
マシンの種類
Machine フィールドには、CPU の種類を指定する次のいずれかの値があります。 イメージ ファイルは、指定したマシン、または指定したマシンをエミュレートするシステムでのみ実行できます。
| 定数 | 値 | 説明 |
|---|---|---|
| IMAGE_FILE_MACHINE_UNKNOWN |
0x0 |
このフィールドの内容は、すべてのマシンの種類に適用されるものと見なされます |
| IMAGE_FILE_MACHINE_ALPHA |
0x184 |
Alpha AXP、32 ビット アドレス空間 |
| IMAGE_FILE_MACHINE_ALPHA64 |
0x284 |
アルファ 64、64 ビットアドレス空間 |
| IMAGE_FILE_MACHINE_AM33 |
0x1d3 |
Matsushita AM33 |
| IMAGE_FILE_MACHINE_AMD64 |
0x8664 |
X64 |
| IMAGE_FILE_MACHINE_ARM |
0x1c0 |
ARM リトル エンディアン |
| IMAGE_FILE_MACHINE_ARM64 |
0xaa64 |
ARM64 リトル エンディアン |
| IMAGE_FILE_MACHINE_ARMNT |
0x1c4 |
ARM Thumb-2 リトル エンディアン |
| IMAGE_FILE_MACHINE_AXP64 |
0x284 |
AXP 64 (アルファ 64 と同じ) |
| IMAGE_FILE_MACHINE_EBC |
0xebc |
EFI バイト コード |
| IMAGE_FILE_MACHINE_I386 |
0x14c |
Intel 386 以降のプロセッサと互換性のあるプロセッサ |
| IMAGE_FILE_MACHINE_IA64 |
0x200 |
Intel Itanium プロセッサ ファミリ |
| IMAGE_FILE_MACHINE_LOONGARCH32 |
0x6232 |
LoongArch 32 ビット プロセッサ ファミリ |
| IMAGE_FILE_MACHINE_LOONGARCH64 |
0x6264 |
LoongArch 64 ビット プロセッサ ファミリ |
| IMAGE_FILE_MACHINE_M32R |
0x9041 |
Mitsubishi M32R リトルエンディアン |
| IMAGE_FILE_MACHINE_MIPS16 |
0x266 |
MIPS16 |
| IMAGE_FILE_MACHINE_MIPSFPU |
0x366 |
FPU を使用した MIPS |
| IMAGE_FILE_MACHINE_MIPSFPU16 |
0x466 |
FPU を使用した MIPS16 |
| IMAGE_FILE_MACHINE_POWERPC |
0x1f0 |
Power PC リトル エンディアン |
| IMAGE_FILE_MACHINE_POWERPCFP |
0x1f1 |
浮動小数点サポートを備えた Power PC |
| IMAGE_FILE_MACHINE_R4000 |
0x166 |
MIPS リトル エンディアン |
| IMAGE_FILE_MACHINE_RISCV32 |
0x5032 |
RISC-V 32 ビット アドレス空間 |
| IMAGE_FILE_MACHINE_RISCV64 |
0x5064 |
RISC-V 64 ビット アドレス空間 |
| IMAGE_FILE_MACHINE_RISCV128 |
0x5128 |
RISC-V 128 ビット アドレス空間 |
| IMAGE_FILE_MACHINE_SH3 |
0x1a2 |
Hitachi SH3 |
| IMAGE_FILE_MACHINE_SH3DSP |
0x1a3 |
Hitachi SH3 DSP |
| IMAGE_FILE_MACHINE_SH4 |
0x1a6 |
Hitachi SH4 |
| IMAGE_FILE_MACHINE_SH5 |
0x1a8 |
Hitachi SH5 |
| IMAGE_FILE_MACHINE_THUMB |
0x1c2 |
つまみ |
| IMAGE_FILE_MACHINE_WCEMIPSV2 |
0x169 |
MIPS リトルエンディアン WCE v2 |
特性
Characteristics フィールドには、オブジェクトまたはイメージ ファイルの属性を示すフラグが含まれています。 現在、次のフラグが定義されています。
| フラグ | 値 | 説明 |
|---|---|---|
| IMAGE_FILE_RELOCS_STRIPPED |
0x0001 |
イメージのみ、Windows CE、Microsoft Windows NT 以降。 これは、ファイルにベース再配置が含まれていないため、指定ベース アドレスで読み込む必要があることを示します。 ベース アドレスが使用できない場合、ローダーはエラーを報告します。 リンカーの既定の動作では、実行可能 (EXE) ファイルからベース再配置が削除されます。 |
| IMAGE_FILE_EXECUTABLE_IMAGE |
0x0002 |
イメージのみ。 これは、イメージ ファイルが有効であり、実行できることを示します。 このフラグが設定されていない場合は、リンカー エラーを示します。 |
| IMAGE_FILE_LINE_NUMS_STRIPPED |
0x0004 |
COFF 行番号が削除されました。 このフラグは非推奨であり、0 にする必要があります。 |
| IMAGE_FILE_LOCAL_SYMS_STRIPPED |
0x0008 |
ローカル シンボルの COFF シンボル テーブル エントリが削除されました。 このフラグは非推奨であり、0 にする必要があります。 |
| IMAGE_FILE_AGGRESSIVE_WS_TRIM |
0x0010 |
互換性のために残されています。 ワーキング セットを積極的にトリミングします。 このフラグは Windows 2000 以降では非推奨であり、0 にする必要があります。 |
| IMAGE_FILE_LARGE_ADDRESS_ AWARE |
0x0020 |
アプリケーションで 2 GB を超えるアドレスを処理できます。 |
| 0x0040 |
このフラグは将来利用するために予約されています。 |
|
| IMAGE_FILE_BYTES_REVERSED_LO |
0x0080 |
リトル エンディアン: メモリ内で最下位ビット (LSB) が最上位ビット (MSB) より先になります。 このフラグは非推奨であり、0 にする必要があります。 |
| IMAGE_FILE_32BIT_MACHINE |
0x0100 |
マシンは 32 ビット ワード アーキテクチャに基づいています。 |
| IMAGE_FILE_DEBUG_STRIPPED |
0x0200 |
デバッグ情報がイメージ ファイルから削除されます。 |
| IMAGE_FILE_REMOVABLE_RUN_ FROM_SWAP |
0x0400 |
イメージがリムーバブル メディア上にある場合は、完全に読み込み、スワップ ファイルにコピーします。 |
| IMAGE_FILE_NET_RUN_FROM_SWAP |
0x0800 |
イメージがネットワーク メディア上にある場合は、完全に読み込み、スワップ ファイルにコピーします。 |
| IMAGE_FILE_SYSTEM |
0x1000 |
イメージ ファイルはシステム ファイルであり、ユーザー プログラムではありません。 |
| IMAGE_FILE_DLL |
0x2000 |
イメージ ファイルはダイナミック リンク ライブラリ (DLL) です。 このようなファイルは、ほぼすべての目的において実行可能ファイルと見なされますが、直接実行することはできません。 |
| IMAGE_FILE_UP_SYSTEM_ONLY |
0x4000 |
ファイルは、単一プロセッサ マシンでのみ実行する必要があります。 |
| IMAGE_FILE_BYTES_REVERSED_HI |
0x8000 |
ビッグ エンディアン: メモリ内で MSB が LSB より先になります。 このフラグは非推奨であり、0 にする必要があります。 |
オプションのヘッダー (イメージのみ)
すべてのイメージ ファイルには、ローダーに情報を提供するオプションのヘッダーがあります。 このヘッダーは、一部のファイル (具体的にはオブジェクト ファイル) に存在しないという意味ではオプションです。 イメージ ファイルの場合は、このヘッダーは必須です。 オブジェクト ファイルにオプションのヘッダーを含めることもできますが、通常、このヘッダーには、オブジェクトファイルでサイズを大きくする以外の機能はありません。
オプションのヘッダーのサイズは固定されていないことに注意してください。 COFF ヘッダーの SizeOfOptionalHeader フィールドを使用して、特定のデータ ディレクトリのファイルへのプローブが SizeOfOptionalHeader を超えていないことを検証する必要があります。 詳細については、「COFF ファイル ヘッダー (オブジェクトとイメージ)」を参照してください。
オプションのヘッダーの NumberOfRvaAndSizes フィールドを使用して、特定のデータ ディレクトリ エントリのプローブがオプションのヘッダーを超えていないことを確認する必要もあります。 また、形式の互換性について、オプションのヘッダー マジック ナンバーを検証することが重要です。
オプションのヘッダー マジック ナンバーは、イメージが PE32 または PE32+ の実行可能ファイルであるかどうかを示します。
| マジック ナンバー | PE 形式 |
|---|---|
| 0x10b |
PE32 |
| 0x20b |
PE32+ |
PE32+ のイメージでは、イメージ サイズを 2 ギガバイトに制限しながら、64 ビットのアドレス空間を処理できます。 その他の PE32+ の変更は、それぞれのセクションで対処されます。
オプションのヘッダー自体には、3 つの主要な部分があります。
| オフセット (PE32/PE32+) | サイズ (PE32/PE32+) | ヘッダー部分 | 説明 |
|---|---|---|---|
| 0 |
28/24 |
標準フィールド |
UNIX を含む COFF のすべての実装に対して定義されているフィールド。 |
| 28/24 |
68/88 |
Windows 固有のフィールド |
Windows の特定の機能 (サブシステムなど) をサポートするための追加フィールド。 |
| 96/112 |
変数 |
データ ディレクトリ |
イメージ ファイルにあり、オペレーティング システムで使用される特殊なテーブル (インポート テーブルやエクスポート テーブルなど) のアドレスとサイズのペア。 |
オプションのヘッダーの標準フィールド (イメージのみ)
オプションのヘッダーの最初の 8 つのフィールドは、COFF の実装ごとに定義される標準フィールドです。 これらのフィールドには、実行可能ファイルの読み込みと実行に役立つ一般的な情報が含まれています。 これらは、PE32+ 形式では変更されません。
| Offset | サイズ | フィールド | 説明 |
|---|---|---|---|
| 0 |
2 |
マジック |
イメージ ファイルの状態を識別する符号なし整数。 最も一般的な数値は、通常の実行可能ファイルとして識別される 0x10B です。 0x107 は ROM イメージとして識別され、0x20B は PE32+ の実行可能ファイルとして識別されます。 |
| 2 |
1 |
MajorLinkerVersion |
リンカーのメジャー バージョン番号。 |
| 3 |
1 |
MinorLinkerVersion |
リンカーのマイナー バージョン番号。 |
| 4 |
4 |
SizeOfCode |
コード (テキスト) セクションのサイズ、またはセクションが複数ある場合はすべてのコード セクションの合計。 |
| 8 |
4 |
SizeOfInitializedData |
初期化されたデータ セクションのサイズ、またはデータ セクションが複数ある場合は、そのようなすべてのセクションの合計。 |
| 12 |
4 |
SizeOfUninitializedData |
初期化されていないデータ セクション (BSS) のサイズ、または BSS セクションが複数ある場合は、そのようなすべてのセクションの合計。 |
| 16 |
4 |
AddressOfEntryPoint |
実行可能ファイルがメモリに読み込まれるときの、イメージ ベースに相対的なエントリ ポイントのアドレス。 プログラム イメージの場合、これは開始アドレスです。 デバイス ドライバーの場合、これは初期化関数のアドレスです。 DLL については、エントリ ポイントはオプションです。 エントリ ポイントが存在しない場合、このフィールドは 0 にする必要があります。 |
| 20 |
4 |
BaseOfCode |
メモリに読み込まれるときの、コードの先頭セクションのイメージ ベースに相対的なアドレス。 |
PE32 には、BaseOfCode に続いて、この追加フィールドが含まれています。これは PE32+ にはありません。
| Offset | サイズ | フィールド | Description |
|---|---|---|---|
| 24 |
4 |
BaseOfData |
メモリに読み込まれるときの、データの先頭セクションのイメージ ベースに相対的なアドレス。 |
オプションのヘッダーの Windows 固有フィールド (イメージのみ)
次の 21 個のフィールドは、COFF のオプションのヘッダー形式の拡張です。 Windows のリンカーとローダーに必要な追加情報が含まれています。
| オフセット (PE32/PE32+) | サイズ (PE32/PE32+) | フィールド | Description |
|---|---|---|---|
| 28/24 |
4/8 |
ImageBase |
メモリに読み込まれるときのイメージの最初のバイトの指定アドレス。64 K の倍数である必要があります。DLL の既定値は 0x10000000 です。 Windows CE EXE の既定値は 0x00010000 です。 Windows NT、Windows 2000、Windows XP、Windows 95、Windows 98、Windows Me の既定値は 0x00400000 です。 |
| 32/32 |
4 |
SectionAlignment |
セクションがメモリに読み込まれるときのその配置 (バイト単位)。 FileAlignment 以上でなければなりません。 既定値は、アーキテクチャのページ サイズです。 |
| 36/36 |
4 |
FileAlignment |
イメージ ファイル内のセクションの生データを揃えるために使用される配置係数 (バイト単位)。 この値は、512 から 64 K (その値を含む) の 2 の累乗にする必要があります。 既定値は 512 です。 SectionAlignment がアーキテクチャのページ サイズより小さい場合は、FileAlignment と SectionAlignment が一致する必要があります。 |
| 40/40 |
2 |
MajorOperatingSystemVersion |
必要なオペレーティング システムのメジャー バージョン番号。 |
| 42/42 |
2 |
MinorOperatingSystemVersion |
必要なオペレーティング システムのマイナー バージョン番号。 |
| 44/44 |
2 |
MajorImageVersion |
イメージのメジャー バージョン番号。 |
| 46/46 |
2 |
MinorImageVersion |
イメージのマイナー バージョン番号。 |
| 48/48 |
2 |
MajorSubsystemVersion |
サブアセンブリのメジャー バージョン番号。 |
| 50/50 |
2 |
MinorSubsystemVersion |
サブアセンブリのマイナー バージョン番号。 |
| 52/52 |
4 |
Win32VersionValue |
予約済み。0 である必要があります。 |
| 56/56 |
4 |
SizeOfImage |
すべてのヘッダーを含む、イメージがメモリに読み込まれるときのイメージのサイズ (バイト単位)。 SectionAlignment の倍数である必要があります。 |
| 60/60 |
4 |
SizeOfHeaders |
FileAlignment の倍数に切り上げられた、MS DOS スタブ、PE ヘッダー、およびセクション ヘッダーの合計サイズ。 |
| 64/64 |
4 |
CheckSum |
イメージ ファイルのチェックサム。 チェックサムを計算するためのアルゴリズムは、IMAGHELP.DLL に組み込まれています。 読み込み時の検証で、すべてのドライバー、ブート時に読み込まれるすべての DLL、重要な Windows プロセスに読み込まれる DLL が確認されます。 |
| 68/68 |
2 |
Subsystem |
このイメージを実行するために必要なサブシステム。 詳細については、「Windows サブシステム」を参照してください。 |
| 70/70 |
2 |
DllCharacteristics |
詳細については、この仕様の後半の「DLL の特性」を参照してください。 |
| 72/72 |
4/8 |
SizeOfStackReserve |
予約するスタックのサイズ。 SizeOfStackCommit のみがコミットされます。残りは、予約サイズに達するまで、一度に 1 ページずつ使用できるようになります。 |
| 76/80 |
4/8 |
SizeOfStackCommit |
コミットするスタックのサイズ。 |
| 80/88 |
4/8 |
SizeOfHeapReserve |
予約するローカル ヒープ領域のサイズ。 SizeOfHeapCommit のみがコミットされます。残りは、予約サイズに達するまで、一度に 1 ページずつ使用できるようになります。 |
| 84/96 |
4/8 |
SizeOfHeapCommit |
コミットするローカル ヒープ領域のサイズ。 |
| 88/104 |
4 |
LoaderFlags |
予約済み。0 である必要があります。 |
| 92/108 |
4 |
NumberOfRvaAndSizes |
オプションのヘッダーの残りの部分にあるデータ ディレクトリ エントリの数。 それぞれによって、場所とサイズが記述されます。 |
Windows サブシステム
オプションのヘッダーの Subsystem フィールドに定義されている次の値によって、イメージの実行に必要な Windows サブシステム (存在する場合) が決まります。
| 定数 | 値 | 説明 |
|---|---|---|
| IMAGE_SUBSYSTEM_UNKNOWN |
0 |
不明なサブシステム |
| IMAGE_SUBSYSTEM_NATIVE |
1 |
デバイス ドライバーとネイティブ Windows プロセス |
| IMAGE_SUBSYSTEM_WINDOWS_GUI |
2 |
Windows グラフィカル ユーザー インターフェイス (GUI) サブシステム |
| IMAGE_SUBSYSTEM_WINDOWS_CUI |
3 |
Windows 文字サブシステム |
| IMAGE_SUBSYSTEM_OS2_CUI |
5 |
OS/2 文字サブシステム |
| IMAGE_SUBSYSTEM_POSIX_CUI |
7 |
Posix 文字サブシステム |
| IMAGE_SUBSYSTEM_NATIVE_WINDOWS |
8 |
ネイティブ Win9x ドライバー |
| IMAGE_SUBSYSTEM_WINDOWS_CE_GUI |
9 |
Windows CE |
| IMAGE_SUBSYSTEM_EFI_APPLICATION |
10 |
拡張ファームウェア インターフェイス (EFI) アプリケーション |
| IMAGE_SUBSYSTEM_EFI_BOOT_ SERVICE_DRIVER |
11 |
ブート サービスを備えた EFI ドライバー |
| IMAGE_SUBSYSTEM_EFI_RUNTIME_ DRIVER |
12 |
ランタイム サービスを備えた EFI ドライバー |
| IMAGE_SUBSYSTEM_EFI_ROM |
13 |
EFI ROM イメージ |
| IMAGE_SUBSYSTEM_XBOX |
14 |
XBOX |
| IMAGE_SUBSYSTEM_WINDOWS_BOOT_APPLICATION |
16 |
Windows ブート アプリケーション。 |
DLL の特性
オプションのヘッダーの DllCharacteristics フィールドには、次の値が定義されています。
| 定数 | 値 | 説明 |
|---|---|---|
| 0x0001 |
予約済み。0 である必要があります。 |
|
| 0x0002 |
予約済み。0 である必要があります。 |
|
| 0x0004 |
予約済み。0 である必要があります。 |
|
| 0x0008 |
予約済み。0 である必要があります。 |
|
| IMAGE_DLLCHARACTERISTICS_HIGH_ENTROPY_VA |
0x0020 |
イメージでは、高エントロピの 64 ビットの仮想アドレス空間を処理できます。 |
| IMAGE_DLLCHARACTERISTICS_ DYNAMIC_BASE |
0x0040 |
DLL は読み込み時に再配置できます。 |
| IMAGE_DLLCHARACTERISTICS_ FORCE_INTEGRITY |
0x0080 |
コードの整合性チェックが適用されます。 |
| IMAGE_DLLCHARACTERISTICS_ NX_COMPAT |
0x0100 |
イメージは NX 互換です。 |
| IMAGE_DLLCHARACTERISTICS_ NO_ISOLATION |
0x0200 |
分離は認識されますが、イメージは分離しないでください。 |
| IMAGE_DLLCHARACTERISTICS_ NO_SEH |
0x0400 |
構造化例外 (SE) 処理は使用されません。 このイメージで SE ハンドラーを呼び出すことはできません。 |
| IMAGE_DLLCHARACTERISTICS_ NO_BIND |
0x0800 |
このイメージはバインドしないでください。 |
| IMAGE_DLLCHARACTERISTICS_APPCONTAINER |
0x1000 |
イメージは AppContainer で実行する必要があります。 |
| IMAGE_DLLCHARACTERISTICS_ WDM_DRIVER |
0x2000 |
WDM ドライバー。 |
| IMAGE_DLLCHARACTERISTICS_GUARD_CF |
0x4000 |
イメージでは、制御フロー ガードがサポートされています。 |
| IMAGE_DLLCHARACTERISTICS_ TERMINAL_SERVER_AWARE |
0x8000 |
ターミナル サーバー対応。 |
オプションのヘッダーのデータ ディレクトリ (イメージのみ)
各データ ディレクトリでは、Windows で使用されるテーブルまたは文字列のアドレスとサイズが指定されます。 システムが実行時に使用できるように、これらのデータ ディレクトリ エントリはすべてメモリに読み込まれます。 データ ディレクトリは、次のように宣言される 8 バイトのフィールドです。
typedef struct _IMAGE_DATA_DIRECTORY {
DWORD VirtualAddress;
DWORD Size;
} IMAGE_DATA_DIRECTORY, *PIMAGE_DATA_DIRECTORY;
最初のフィールド VirtualAddress は、実際にはテーブルの RVA です。 RVA は、テーブルの読み込み時のイメージのベース アドレスに対する相対的なテーブルのアドレスです。 2 番目のフィールドは、サイズをバイト単位で示します。 オプションのヘッダーの最後の部分を形成するデータ ディレクトリの一覧を次の表に示します。
ディレクトリの数は固定されていないことに注意してください。 特定のディレクトリを探す前に、オプションのヘッダーの NumberOfRvaAndSizes フィールドを確認します。
また、このテーブルの RVA がセクションの先頭を指していること、および特定のテーブルを含むセクションに特定の名前があることを前提としないでください。
| オフセット (PE/PE32+) | サイズ | フィールド | Description |
|---|---|---|---|
| 96/112 |
8 |
Export Table |
エクスポート テーブルのアドレスとサイズ。 詳細については、「.edata セクション (イメージのみ)」を参照してください。 |
| 104/120 |
8 |
Import Table |
インポート テーブルのアドレスとサイズ。 詳細については、「.idata セクション」を参照してください。 |
| 112/128 |
8 |
Resource Table |
リソース テーブルのアドレスとサイズ。 詳細については、「.rsrc セクション」を参照してください。 |
| 120/136 |
8 |
Exception Table |
例外テーブルのアドレスとサイズ。 詳細については、「.pdata セクション照してください。 |
| 128/144 |
8 |
Certificate Table |
属性証明書テーブルのアドレスとサイズ。 詳細については、「属性証明書テーブル (イメージのみ)照してください。 |
| 136/152 |
8 |
Base Relocation Table |
ベース再配置テーブルのアドレスとサイズ。 詳細については、「.reloc セクション (イメージのみ)」を参照してください。 |
| 144/160 |
8 |
デバッグ |
デバッグ データの開始アドレスとサイズ。 詳細については、｢.debug セクション」を参照してください。 |
| 152/168 |
8 |
アーキテクチャ |
予約済み。0 である必要があります |
| 160/176 |
8 |
Global Ptr |
グローバル ポインター レジスタに格納される値の RVA。 この構造体のサイズ メンバーは 0 に設定する必要があります。 |
| 168/184 |
8 |
TLS Table |
スレッド ローカル ストレージ (TLS) テーブルのアドレスとサイズ。 詳細については、「.tls セクション」を参照してください。 |
| 176/192 |
8 |
Load Config Table |
読み込み構成テーブルのアドレスとサイズ。 詳細については、「読み込み構成構造体 (イメージのみ)」を参照してください。 |
| 184/200 |
8 |
Bound Import |
バインド インポート テーブルのアドレスとサイズ。 |
| 192/208 |
8 |
IAT |
インポート アドレス テーブルのアドレスとサイズ。 詳細については、「インポート アドレス テーブル」を参照してください。 |
| 200/216 |
8 |
Delay Import Descriptor |
遅延インポート記述子のアドレスとサイズ。 詳細については、「遅延読み込みインポート テーブル (イメージのみ)」を参照してください。 |
| 208/224 |
8 |
CLR Runtime Header |
CLR ランタイム ヘッダーのアドレスとサイズ。 詳細については、「.cormeta セクション (オブジェクトのみ)」を参照してください。 |
| 216/232 |
8 |
予約済み。0 である必要があります |
属性証明書テーブル エントリは、属性証明書のテーブルを指します。 これらの証明書は、イメージの一部としてメモリに読み込まれません。 そのため、通常は RVA であるこのエントリの最初のフィールドは、代わりにファイル ポインターです。
セクション テーブル (セクション ヘッダー)
セクション テーブルの各行は、実質的にはセクション ヘッダーです。 このテーブルは、オプションのヘッダー (存在する場合) の直後に配置されます。 この配置が必要なのは、ファイル ヘッダーにセクション テーブルへの直接ポインターが含まれていないためです。 代わりに、セクション テーブルの場所は、ヘッダーの後の最初のバイトの位置を計算して決定されます。 ファイル ヘッダーで指定されているオプションのヘッダーのサイズを必ず使用してください。
セクション テーブル内のエントリの数は、ファイル ヘッダーの NumberOfSections フィールドによって指定されます。 セクション テーブルのエントリには、1 から始まる番号が付けられます。 コードとデータ メモリ セクションのエントリは、リンカーによって選択された順序になります。
イメージ ファイルでは、セクションの VA は、昇順および隣接するようにリンカーによって割り当てられる必要があります。また、オプションのヘッダーの SectionAlignment 値の倍数である必要があります。
各セクション ヘッダー (セクション テーブル エントリ) の形式は次のようになり、エントリあたり合計 40 バイトです。
| Offset | サイズ | フィールド | 説明 |
|---|---|---|---|
| 0 |
8 |
名前 |
8 バイトの NULL 埋め込み UTF-8 エンコード文字列。 文字列の長さがちょうど 8 文字の場合、終端の null はありません。 長い名前の場合、このフィールドにはスラッシュ (/) が含まれます。その後に、文字列テーブルへのオフセットである 10 進数の ASCII 表現が続きます。 実行可能イメージでは文字列テーブルが使用されず、8 文字を超えるセクション名はサポートされません。 オブジェクト ファイル内の長い名前は、実行可能ファイルに出力されると切り詰められます。 |
| 8 |
4 |
VirtualSize |
メモリに読み込まれるときのセクションの合計サイズ。 この値が SizeOfRawData より大きい場合、セクションには 0 が埋め込まれます。 このフィールドは実行可能イメージに対してのみ有効であり、オブジェクト ファイルの場合は 0 に設定する必要があります。 |
| 12 |
4 |
VirtualAddress |
実行可能イメージの場合、セクションがメモリに読み込まれるときの、イメージ ベースに相対的なセクションの最初のバイトのアドレス。 オブジェクト ファイルの場合、このフィールドは再配置が適用される前の最初のバイトのアドレスです。わかりやすくするために、コンパイラによってこれを 0 に設定する必要があります。 それ以外の場合は、再配置中にオフセットから引かれる任意の値です。 |
| 16 |
4 |
SizeOfRawData |
セクションのサイズ (オブジェクト ファイルの場合) またはディスク上で初期化されたデータのサイズ (イメージ ファイルの場合)。 実行可能イメージの場合、これはオプションのヘッダーの FileAlignment の倍数である必要があります。 これが VirtualSize より小さい場合、セクションの残りの部分は 0 で埋められます。 SizeOfRawData フィールドは丸められますが、VirtualSize フィールドは丸められないため、SizeOfRawData が VirtualSize より大きくなる場合もあります。 セクションに初期化されていないデータのみが含まれている場合、このフィールドは 0 にする必要があります。 |
| 20 |
4 |
PointerToRawData |
COFF ファイル内のセクションの先頭ページへのファイル ポインター。 実行可能イメージの場合、これはオプションのヘッダーの FileAlignment の倍数である必要があります。 オブジェクト ファイルの場合、最高のパフォーマンスを得るために、値を 4 バイト境界に合わせる必要があります。 セクションに初期化されていないデータのみが含まれている場合、このフィールドは 0 にする必要があります。 |
| 24 |
4 |
PointerToRelocations |
セクションの再配置エントリの先頭へのファイル ポインター。 実行可能イメージの場合、または再配置がない場合は 0 に設定されます。 |
| 28 |
4 |
PointerToLinenumbers |
セクションの行番号エントリの先頭へのファイル ポインター。 COFF 行番号がない場合は 0 に設定されます。 COFF デバッグ情報は非推奨であるため、イメージの場合、この値は 0 にする必要があります。 |
| 32 |
2 |
NumberOfRelocations |
セクションの再配置エントリの数。 実行可能イメージの場合は 0 に設定されます。 |
| 34 |
2 |
NumberOfLinenumbers |
セクションの行番号エントリの数。 COFF デバッグ情報は非推奨であるため、イメージの場合、この値は 0 にする必要があります。 |
| 36 |
4 |
特性 |
セクションの特性を記述したフラグ。 詳細については、「セクション フラグ」を参照してください。 |
セクション フラグ
セクション ヘッダーの Characteristics フィールドのセクション フラグは、セクションの特性を示します。
| フラグ | 値 | 説明 |
|---|---|---|
| 0x00000000 |
将来利用するために予約されています。 |
|
| 0x00000001 |
将来利用するために予約されています。 |
|
| 0x00000002 |
将来利用するために予約されています。 |
|
| 0x00000004 |
将来利用するために予約されています。 |
|
| IMAGE_SCN_TYPE_NO_PAD |
0x00000008 |
セクションは、次の境界まで埋め込みできません。 このフラグは廃止され、IMAGE_SCN_ALIGN_1BYTES に置き換えられます。 これは、オブジェクト ファイルの場合のみ有効です。 |
| 0x00000010 |
将来利用するために予約されています。 |
|
| IMAGE_SCN_CNT_CODE |
0x00000020 |
セクションに実行可能コードが含まれています。 |
| IMAGE_SCN_CNT_INITIALIZED_DATA |
0x00000040 |
セクションに初期化されたデータが含まれています。 |
| IMAGE_SCN_CNT_UNINITIALIZED_ DATA |
0x00000080 |
セクションに初期化されていないデータが含まれています。 |
| IMAGE_SCN_LNK_OTHER |
0x00000100 |
将来利用するために予約されています。 |
| IMAGE_SCN_LNK_INFO |
0x00000200 |
セクションにコメントまたはその他の情報が含まれています。 .drectve セクションには、この種類があります。 これは、オブジェクト ファイルの場合のみ有効です。 |
| 0x00000400 |
将来利用するために予約されています。 |
|
| IMAGE_SCN_LNK_REMOVE |
0x00000800 |
セクションはイメージの一部になりません。 これは、オブジェクト ファイルの場合のみ有効です。 |
| IMAGE_SCN_LNK_COMDAT |
0x00001000 |
セクションに COMDAT データが含まれています。 詳細については、「COMDAT セクション (オブジェクトのみ)」を参照してください。 これは、オブジェクト ファイルの場合のみ有効です。 |
| IMAGE_SCN_GPREL |
0x00008000 |
セクションにグローバル ポインター (GP) を介して参照されるデータが含まれています。 |
| IMAGE_SCN_MEM_PURGEABLE |
0x00020000 |
将来利用するために予約されています。 |
| IMAGE_SCN_MEM_16BIT |
0x00020000 |
将来利用するために予約されています。 |
| IMAGE_SCN_MEM_LOCKED |
0x00040000 |
将来利用するために予約されています。 |
| IMAGE_SCN_MEM_PRELOAD |
0x00080000 |
将来利用するために予約されています。 |
| IMAGE_SCN_ALIGN_1BYTES |
0x00100000 |
データを 1 バイト境界に配置します。 オブジェクト ファイルの場合のみ有効です。 |
| IMAGE_SCN_ALIGN_2BYTES |
0x00200000 |
データを 2 バイト境界に配置します。 オブジェクト ファイルの場合のみ有効です。 |
| IMAGE_SCN_ALIGN_4BYTES |
0x00300000 |
データを 4 バイト境界に配置します。 オブジェクト ファイルの場合のみ有効です。 |
| IMAGE_SCN_ALIGN_8BYTES |
0x00400000 |
データを 8 バイト境界に配置します。 オブジェクト ファイルの場合のみ有効です。 |
| IMAGE_SCN_ALIGN_16BYTES |
0x00500000 |
データを 16 バイト境界に配置します。 オブジェクト ファイルの場合のみ有効です。 |
| IMAGE_SCN_ALIGN_32BYTES |
0x00600000 |
データを 32 バイト境界に配置します。 オブジェクト ファイルの場合のみ有効です。 |
| IMAGE_SCN_ALIGN_64BYTES |
0x00700000 |
データを 64 バイト境界に配置します。 オブジェクト ファイルの場合のみ有効です。 |
| IMAGE_SCN_ALIGN_128BYTES |
0x00800000 |
データを 128 バイト境界に配置します。 オブジェクト ファイルの場合のみ有効です。 |
| IMAGE_SCN_ALIGN_256BYTES |
0x00900000 |
データを 256 バイト境界に配置します。 オブジェクト ファイルの場合のみ有効です。 |
| IMAGE_SCN_ALIGN_512BYTES |
0x00A00000 |
データを 512 バイト境界に配置します。 オブジェクト ファイルの場合のみ有効です。 |
| IMAGE_SCN_ALIGN_1024BYTES |
0x00B00000 |
データを 1024 バイト境界に配置します。 オブジェクト ファイルの場合のみ有効です。 |
| IMAGE_SCN_ALIGN_2048BYTES |
0x00C00000 |
データを 2048 バイト境界に配置します。 オブジェクト ファイルの場合のみ有効です。 |
| IMAGE_SCN_ALIGN_4096BYTES |
0x00D00000 |
データを 4096 バイト境界に配置します。 オブジェクト ファイルの場合のみ有効です。 |
| IMAGE_SCN_ALIGN_8192BYTES |
0x00E00000 |
データを 8192 バイト境界に配置します。 オブジェクト ファイルの場合のみ有効です。 |
| IMAGE_SCN_LNK_NRELOC_OVFL |
0x01000000 |
セクションに拡張された再配置が含まれています。 |
| IMAGE_SCN_MEM_DISCARDABLE |
0x02000000 |
セクションは必要に応じて破棄できます。 |
| IMAGE_SCN_MEM_NOT_CACHED |
0x04000000 |
セクションはキャッシュできません。 |
| IMAGE_SCN_MEM_NOT_PAGED |
0x08000000 |
セクションはページングできません。 |
| IMAGE_SCN_MEM_SHARED |
0x10000000 |
セクションはメモリ内で共有できます。 |
| IMAGE_SCN_MEM_EXECUTE |
0x20000000 |
セクションはコードとして実行できます。 |
| IMAGE_SCN_MEM_READ |
0x40000000 |
セクションは読み取ることができます。 |
| IMAGE_SCN_MEM_WRITE |
0x80000000 |
セクションに書き込むことができます。 |
IMAGE_SCN_LNK_NRELOC_OVFL は、セクションの再配置の数が、セクション ヘッダーで予約されている 16 ビットを超えていることを示します。 ビットが設定され、セクション ヘッダーの NumberOfRelocations フィールドが 0xffff の場合、実際の再配置数は、最初の再配置の 32 ビット VirtualAddress フィールドに格納されます。 IMAGE_SCN_LNK_NRELOC_OVFL が設定されていて、セクション内の再配置が 0xffff よりも少ない場合は、エラーになります。
グループ化されたセクション (オブジェクトのみ)
"$" 文字 (ドル記号) には、オブジェクト ファイル内のセクション名に特別な解釈があります。
オブジェクト セクションの内容を含むイメージ セクションを決定すると、リンカーは "$" とその後に続くすべての文字を破棄します。 したがって、.text$X という名前のオブジェクト セクションは、実際にはイメージの .text セクションに提供されます。
ただし、"$" の後の文字によって、イメージ セクションへのコントリビューションの順序が決まります。 同じオブジェクト セクション名を持つすべての提供対象がイメージに連続して割り当てられ、提供対象のブロックは、オブジェクト セクション名で辞書順に並べ替えられます。 したがって、.text$X というセクション名のオブジェクト ファイル内のすべての内容が、.text$W の提供対象の後、かつ .text$Y の提供対象の前にまとめられます。
イメージ ファイル内のセクション名に "$" 文字が含まれることはありません。
ファイルのその他の内容
- セクション データ
- COFF 再配置 (オブジェクトのみ)
- COFF 行番号 (非推奨)
- COFF シンボル テーブル
- 補助シンボル レコード
- COFF 文字列テーブル
- 属性証明書テーブル (イメージのみ)
- 遅延読み込みインポート テーブル
これまでに説明したデータ構造 (オプションのヘッダーまで含む) はすべて、ファイルの先頭 (または、ファイルが MS-DOS スタブを含むイメージの場合は PE ヘッダー) からの固定オフセットに配置されます。
COFF オブジェクトまたはイメージ ファイルの残りの部分には、必ずしも特定のファイル オフセットに配置されるとは限らないデータのブロックが含まれます。 その場所はオプションのヘッダーまたはセクション ヘッダー内のポインターによって定義されます。
SectionAlignment 値がアーキテクチャのページ サイズより小さいイメージの場合は例外です (Intel x86 および MIPS の場合は 4 K、Itanium の場合は 8 K)。 SectionAlignment の説明については、「オプションのヘッダー (イメージのみ)」を参照してください。 この場合、セクション 5.1「セクション データ」で説明されているように、セクション データのファイル オフセットに制約があります。もう 1 つの例外は、属性証明書とデバッグ情報をイメージ ファイルの末尾に配置し、属性証明書テーブルはデバッグ セクションのすぐ前に配置する必要があることです。これは、ローダーによってこれらがメモリにマップされないためです。 ただし、属性証明書とデバッグ情報に関するこのルールは、オブジェクト ファイルには適用されません。
セクション データ
セクションの初期化されたデータは、単純なバイトのブロックで構成されます。 ただし、含まれているのがすべて 0 のセクションでは、セクション データを含める必要はありません。
各セクションのデータは、セクション ヘッダーの PointerToRawData フィールドによって指定されたファイル オフセットに配置されます。 ファイル内でのこのデータのサイズは、SizeOfRawData フィールドによって示されます。 SizeOfRawData が VirtualSize より小さい場合、残りの部分には 0 が埋め込まれます。
イメージ ファイルでは、セクション データは、オプションのヘッダーの FileAlignment フィールドで指定された境界に配置する必要があります。 セクション データは、対応するセクションの RVA 値の順に配置する必要があります (セクション テーブルの個々のセクション ヘッダーと同様)。
オプションのヘッダーの SectionAlignment 値がアーキテクチャのページ サイズより小さい場合、イメージ ファイルにはさらに制約があります。 このようなファイルの場合、ファイル内のセクション データの場所は、イメージが読み込まれたときのメモリ内の場所と一致する必要があります。これにより、セクション データの物理的なオフセットが RVA と同じになります。
COFF 再配置 (オブジェクトのみ)
オブジェクト ファイルには COFF 再配置が含まれています。これは、セクション データがイメージ ファイルに配置され、その後メモリに読み込まれるときに、どのように変更されるべきかを指定します。
イメージ ファイルには COFF 再配置が含まれていません。これは、すべての参照されるシンボルにフラット アドレス空間でのアドレスが既に割り当てられているためです。 イメージには、(イメージに IMAGE_FILE_RELOCS_STRIPPED 属性がない限り) .reloc セクションのベース再配置の形式で再配置情報が含まれます。 詳細については、「.reloc セクション (イメージのみ)」を参照してください。
オブジェクト ファイル内のセクションごとに、固定長レコードの配列にセクションの COFF 再配置が含まれます。 配列の位置と長さはセクション ヘッダーで指定されます。 配列の各要素の形式は次のとおりです。
| Offset | サイズ | フィールド | 説明 |
|---|---|---|---|
| 0 |
4 |
VirtualAddress |
再配置が適用される項目のアドレス。 これは、セクションの先頭からのオフセットに、セクションの RVA/Offset フィールドの値を足したものです。 「セクション テーブル (セクション ヘッダー)」を参照してください。 たとえば、セクションの最初のバイトのアドレスが 0x10 の場合、第 3 バイトのアドレスは 0x12 です。 |
| 4 |
4 |
SymbolTableIndex |
シンボル テーブルへの 0 から始まるインデックス。 このシンボルは、再配置に使用されるアドレスを示します。 指定したシンボルにセクション ストレージ クラスがある場合、シンボルのアドレスは、同じ名前の最初のセクションのアドレスです。 |
| 8 |
2 |
Type |
実行する必要がある再配置の種類を示す値。 有効な再配置の種類は、マシンの種類によって異なります。 「種類インジケーター」を参照してください。 |
SymbolTableIndex フィールドによって参照されるシンボルにストレージ クラス IMAGE_SYM_CLASS_SECTION がある場合、シンボルのアドレスはセクションの先頭になります。 セクションは通常は同じファイル内にありますが、オブジェクト ファイルがアーカイブ (ライブラリ) の一部である場合は除きます。 その場合、セクションは、現在のオブジェクト ファイルと同じアーカイブ メンバー名を持つアーカイブ内の他のオブジェクト ファイルにあります。 (アーカイブ メンバー名とのリレーションシップは、インポート テーブル、つまり .idata セクションのリンクで使用されます)。
種類インジケーター
再配置レコードの Type フィールドは、実行する必要がある再配置の種類を示します。 マシンの種類ごとに異なる再配置の種類が定義されます。
x64 プロセッサ
x64 および互換性のあるプロセッサでは、次の再配置の種類インジケーターが定義されています。
| 定数 | 値 | 説明 |
|---|---|---|
| IMAGE_REL_AMD64_ABSOLUTE |
0x0000 |
この再配置は無視されます。 |
| IMAGE_REL_AMD64_ADDR64 |
0x0001 |
再配置ターゲットの 64 ビット VA。 |
| IMAGE_REL_AMD64_ADDR32 |
0x0002 |
再配置ターゲットの 32 ビット VA。 |
| IMAGE_REL_AMD64_ADDR32NB |
0x0003 |
イメージ ベース (RVA) のない 32 ビット アドレス。 |
| IMAGE_REL_AMD64_REL32 |
0x0004 |
再配置の後のバイトからの 32 ビット相対アドレス。 |
| IMAGE_REL_AMD64_REL32_1 |
0x0005 |
再配置からのバイト距離 1 に相対する 32 ビット アドレス。 |
| IMAGE_REL_AMD64_REL32_2 |
0x0006 |
再配置からのバイト距離 2 に相対する 32 ビット アドレス。 |
| IMAGE_REL_AMD64_REL32_3 |
0x0007 |
再配置からのバイト距離 3 に相対する 32 ビット アドレス。 |
| IMAGE_REL_AMD64_REL32_4 |
0x0008 |
再配置からのバイト距離 4 に相対する 32 ビット アドレス。 |
| IMAGE_REL_AMD64_REL32_5 |
0x0009 |
再配置からのバイト距離 5 に相対する 32 ビット アドレス。 |
| IMAGE_REL_AMD64_SECTION |
0x000A |
ターゲットを含むセクションの 16 ビット セクション インデックス。 これは、デバッグ情報をサポートするために使用されます。 |
| IMAGE_REL_AMD64_SECREL |
0x000B |
セクションの先頭からのターゲットの 32 ビット オフセット。 これは、デバッグ情報と静的スレッド ローカル ストレージをサポートするために使用されます。 |
| IMAGE_REL_AMD64_SECREL7 |
0x000C |
ターゲットを含むセクションのベースからの 7 ビット符号なしオフセット。 |
| IMAGE_REL_AMD64_TOKEN |
0x000D |
CLR トークン。 |
| IMAGE_REL_AMD64_SREL32 |
0x000E |
オブジェクトに出力される 32 ビット符号付きスパン依存値。 |
| IMAGE_REL_AMD64_PAIR |
0x000F |
すべてのスパン依存値の直後に必要なペア。 |
| IMAGE_REL_AMD64_SSPAN32 |
0x0010 |
リンク時に適用される 32 ビット符号付きスパン依存値。 |
ARM プロセッサ
ARM プロセッサには、次の再配置の種類インジケーターが定義されています。
| 定数 | 値 | 説明 |
|---|---|---|
| IMAGE_REL_ARM_ABSOLUTE |
0x0000 |
この再配置は無視されます。 |
| IMAGE_REL_ARM_ADDR32 |
0x0001 |
ターゲットの 32 ビット VA。 |
| IMAGE_REL_ARM_ADDR32NB |
0x0002 |
ターゲットの 32 ビット RVA。 |
| IMAGE_REL_ARM_BRANCH24 |
0x0003 |
ターゲットに対する 24 ビットの相対変位。 |
| IMAGE_REL_ARM_BRANCH11 |
0x0004 |
サブルーチン呼び出しへの参照。 この参照は、11 ビット オフセットを持つ 2 つの 16 ビット命令で構成されます。 |
| IMAGE_REL_ARM_REL32 |
0x000A |
再配置の後のバイトからの 32 ビット相対アドレス。 |
| IMAGE_REL_ARM_SECTION |
0x000E |
ターゲットを含むセクションの 16 ビット セクション インデックス。 これは、デバッグ情報をサポートするために使用されます。 |
| IMAGE_REL_ARM_SECREL |
0x000F |
セクションの先頭からのターゲットの 32 ビット オフセット。 これは、デバッグ情報と静的スレッド ローカル ストレージをサポートするために使用されます。 |
| IMAGE_REL_ARM_MOV32 |
0x0010 |
ターゲットの 32 ビット VA。 この再配置は、下位 16 ビットの MOVW 命令を使用して適用されます。その後に、上位 16 ビットの MOVT が続きます。 |
| IMAGE_REL_THUMB_MOV32 |
0x0011 |
ターゲットの 32 ビット VA。 この再配置は、下位 16 ビットの MOVW 命令を使用して適用されます。その後に、上位 16 ビットの MOVT が続きます。 |
| IMAGE_REL_THUMB_BRANCH20 |
0x0012 |
この命令は、2 バイト配置ターゲットに対する 21 ビットの相対変位でフィックスアップされます。 変位の最下位ビットは常に 0 であり、格納されません。 この再配置は、Thumb-2 32 ビット条件付き B 命令に対応します。 |
| 未使用 |
0x0013 |
|
| IMAGE_REL_THUMB_BRANCH24 |
0x0014 |
この命令は、2 バイト配置ターゲットに対する 25 ビットの相対変位でフィックスアップされます。 変位の最下位ビットは 0 であり、格納されません。この再配置は、Thumb-2 B 命令に対応します。 |
| IMAGE_REL_THUMB_BLX23 |
0x0015 |
この命令は、4 バイト配置ターゲットに対する 25 ビットの相対変位でフィックスアップされます。 変位の下位 2 ビットは 0 であり、格納されません。 この再配置は、Thumb-2 BLX 命令に対応します。 |
| IMAGE_REL_ARM_PAIR |
0x0016 |
この再配置は、ARM_REFHI または THUMB_REFHI の直後である場合のみ有効です。 SymbolTableIndex には、シンボル テーブルへのインデックスではなく、変位が含まれています。 |
ARM64 プロセッサ
ARM64 プロセッサには、次の再配置の種類インジケーターが定義されています。
| 定数 | 値 | 説明 |
|---|---|---|
| IMAGE_REL_ARM64_ABSOLUTE |
0x0000 |
この再配置は無視されます。 |
| IMAGE_REL_ARM64_ADDR32 |
0x0001 |
ターゲットの 32 ビット VA。 |
| IMAGE_REL_ARM64_ADDR32NB |
0x0002 |
ターゲットの 32 ビット RVA。 |
| IMAGE_REL_ARM64_BRANCH26 |
0x0003 |
ターゲットに対する 26 ビットの相対変位。B および BL 命令用。 |
| IMAGE_REL_ARM64_PAGEBASE_REL21 |
0x0004 |
ターゲットのページ ベース。ADRP 命令用。 |
| IMAGE_REL_ARM64_REL21 |
0x0005 |
ターゲットに対する 12 ビットの相対変位。命令 ADR 用。 |
| IMAGE_REL_ARM64_PAGEOFFSET_12A |
0x0006 |
ターゲットの 12 ビット ページ オフセット。ゼロ シフトの命令 ADD/ADDS用 (イミディエイト)。 |
| IMAGE_REL_ARM64_PAGEOFFSET_12L |
0x0007 |
ターゲットの 12 ビット ページ オフセット。命令 LDR 用 (インデックス付き、符号なしイミディエイト)。 |
| IMAGE_REL_ARM64_SECREL |
0x0008 |
セクションの先頭からのターゲットの 32 ビット オフセット。 これは、デバッグ情報と静的スレッド ローカル ストレージをサポートするために使用されます。 |
| IMAGE_REL_ARM64_SECREL_LOW12A |
0x0009 |
ターゲットのセクション オフセットのビット 0:11。ゼロ シフトの命令 ADD/ADDS (イミディエイト) 用。 |
| IMAGE_REL_ARM64_SECREL_HIGH12A |
0x000A |
ターゲットのセクション オフセットのビット 12:23。ゼロ シフトの命令 ADD/ADDS (イミディエイト) 用。 |
| IMAGE_REL_ARM64_SECREL_LOW12L |
0x000B |
ターゲットのセクション オフセットのビット 0:11。命令 LDR (インデックス付き、符号なしイミディエイト) 用。 |
| IMAGE_REL_ARM64_TOKEN |
0x000C |
CLR トークン。 |
| IMAGE_REL_ARM64_SECTION |
0x000D |
ターゲットを含むセクションの 16 ビット セクション インデックス。 これは、デバッグ情報をサポートするために使用されます。 |
| IMAGE_REL_ARM64_ADDR64 |
0x000E |
再配置ターゲットの 64 ビット VA。 |
| IMAGE_REL_ARM64_BRANCH19 |
0x000F |
再配置ターゲットへの 19 ビット オフセット。条件付き B 命令用。 |
| IMAGE_REL_ARM64_BRANCH14 |
0x0010 |
再配置ターゲットへの 14 ビット オフセット。命令 TBZ および TBNZ 用。 |
| IMAGE_REL_ARM64_REL32 |
0x0011 |
再配置の後のバイトからの 32 ビット相対アドレス。 |
Hitachi SuperH プロセッサ
SH3 および SH4 プロセッサには、次の再配置の種類インジケーターが定義されています。 SH5 固有の再配置は、SHM (SH Media) として示されます。
| 定数 | 値 | 説明 |
|---|---|---|
| IMAGE_REL_SH3_ABSOLUTE |
0x0000 |
この再配置は無視されます。 |
| IMAGE_REL_SH3_DIRECT16 |
0x0001 |
ターゲット シンボルの VA を含む 16 ビット位置への参照。 |
| IMAGE_REL_SH3_DIRECT32 |
0x0002 |
ターゲット シンボルの 32 ビット VA。 |
| IMAGE_REL_SH3_DIRECT8 |
0x0003 |
ターゲット シンボルの VA を含む 8 ビット位置への参照。 |
| IMAGE_REL_SH3_DIRECT8_WORD |
0x0004 |
ターゲット シンボルの有効な 16 ビット VA を含む 8 ビット命令への参照。 |
| IMAGE_REL_SH3_DIRECT8_LONG |
0x0005 |
ターゲット シンボルの有効な 32 ビット VA を含む 8 ビット命令への参照。 |
| IMAGE_REL_SH3_DIRECT4 |
0x0006 |
下位 4 ビットにターゲット シンボルの VA が含まれる 8 ビット位置への参照。 |
| IMAGE_REL_SH3_DIRECT4_WORD |
0x0007 |
下位 4 ビットにターゲット シンボルの有効な 16 ビット VA が含まれる 8 ビット命令への参照。 |
| IMAGE_REL_SH3_DIRECT4_LONG |
0x0008 |
下位 4 ビットにターゲット シンボルの有効な 32 ビット VA が含まれる 8 ビット命令への参照。 |
| IMAGE_REL_SH3_PCREL8_WORD |
0x0009 |
ターゲット シンボルの有効な 16 ビット相対オフセットを含む 8 ビット命令への参照。 |
| IMAGE_REL_SH3_PCREL8_LONG |
0x000A |
ターゲット シンボルの有効な 32 ビット相対オフセットを含む 8 ビット命令への参照。 |
| IMAGE_REL_SH3_PCREL12_WORD |
0x000B |
下位 12 ビットにターゲット シンボルの有効な 16 ビット相対オフセットが含まれる 16 ビット命令への参照。 |
| IMAGE_REL_SH3_STARTOF_SECTION |
0x000C |
ターゲット シンボル含むセクションの VA である 32 ビット位置への参照。 |
| IMAGE_REL_SH3_SIZEOF_SECTION |
0x000D |
ターゲット シンボル含むセクションのサイズである 32 ビット位置への参照。 |
| IMAGE_REL_SH3_SECTION |
0x000E |
ターゲットを含むセクションの 16 ビット セクション インデックス。 これは、デバッグ情報をサポートするために使用されます。 |
| IMAGE_REL_SH3_SECREL |
0x000F |
セクションの先頭からのターゲットの 32 ビット オフセット。 これは、デバッグ情報と静的スレッド ローカル ストレージをサポートするために使用されます。 |
| IMAGE_REL_SH3_DIRECT32_NB |
0x0010 |
ターゲット シンボルの 32 ビット RVA。 |
| IMAGE_REL_SH3_GPREL4_LONG |
0x0011 |
GP 相対。 |
| IMAGE_REL_SH3_TOKEN |
0x0012 |
CLR トークン。 |
| IMAGE_REL_SHM_PCRELPT |
0x0013 |
ロングワードでの現在の命令からのオフセット。 NOMODE ビットが設定されていない場合は、下位ビットの反転をビット 32 に挿入して、PTA または PTB を選択します。 |
| IMAGE_REL_SHM_REFLO |
0x0014 |
32 ビット アドレスの下位 16 ビット。 |
| IMAGE_REL_SHM_REFHALF |
0x0015 |
32 ビット アドレスの上位 16 ビット。 |
| IMAGE_REL_SHM_RELLO |
0x0016 |
相対アドレスの下位 16 ビット。 |
| IMAGE_REL_SHM_RELHALF |
0x0017 |
相対アドレスの上位 16 ビット。 |
| IMAGE_REL_SHM_PAIR |
0x0018 |
この再配置は、REFHALF、RELHALF、または RELLO 再配置の直後である場合にのみ有効です。 この再配置の SymbolTableIndex フィールドには、シンボル テーブルへのインデックスではなく、変位が含まれます。 |
| IMAGE_REL_SHM_NOMODE |
0x8000 |
再配置はセクション モードを無視します。 |
IBM PowerPC プロセッサ
PowerPC プロセッサには、次の再配置の種類インジケーターが定義されています。
| 定数 | 値 | 説明 |
|---|---|---|
| IMAGE_REL_PPC_ABSOLUTE |
0x0000 |
この再配置は無視されます。 |
| IMAGE_REL_PPC_ADDR64 |
0x0001 |
ターゲットの 64 ビット VA。 |
| IMAGE_REL_PPC_ADDR32 |
0x0002 |
ターゲットの 32 ビット VA。 |
| IMAGE_REL_PPC_ADDR24 |
0x0003 |
ターゲットの VA の下位 24 ビット。 これは、ターゲット シンボルが絶対であり、その元の値に符号拡張できる場合にのみ有効です。 |
| IMAGE_REL_PPC_ADDR16 |
0x0004 |
ターゲットの VA の下位 16 ビット。 |
| IMAGE_REL_PPC_ADDR14 |
0x0005 |
ターゲットの VA の下位 14 ビット。 これは、ターゲット シンボルが絶対であり、その元の値に符号拡張できる場合にのみ有効です。 |
| IMAGE_REL_PPC_REL24 |
0x0006 |
シンボルの位置に対する 24 ビット PC 相対オフセット。 |
| IMAGE_REL_PPC_REL14 |
0x0007 |
シンボルの位置に対する 14 ビット PC 相対オフセット。 |
| IMAGE_REL_PPC_ADDR32NB |
0x000A |
ターゲットの 32 ビット RVA。 |
| IMAGE_REL_PPC_SECREL |
0x000B |
セクションの先頭からのターゲットの 32 ビット オフセット。 これは、デバッグ情報と静的スレッド ローカル ストレージをサポートするために使用されます。 |
| IMAGE_REL_PPC_SECTION |
0x000C |
ターゲットを含むセクションの 16 ビット セクション インデックス。 これは、デバッグ情報をサポートするために使用されます。 |
| IMAGE_REL_PPC_SECREL16 |
0x000F |
セクションの先頭からのターゲットの 16 ビット オフセット。 これは、デバッグ情報と静的スレッド ローカル ストレージをサポートするために使用されます。 |
| IMAGE_REL_PPC_REFHI |
0x0010 |
ターゲットの 32 ビット VA の上位 16 ビット。 これは、完全なアドレスを読み込む 2 命令シーケンスの最初の命令に使用されます。 この再配置の直後に PAIR 再配置が続く必要があります。その SymbolTableIndex には、再配置される位置から取得された上位 16 ビットに追加される符号付き 16 ビット変位が含まれます。 |
| IMAGE_REL_PPC_REFLO |
0x0011 |
ターゲットの VA の下位 16 ビット。 |
| IMAGE_REL_PPC_PAIR |
0x0012 |
REFHI または SECRELHI 再配置の直後である場合にのみ有効な再配置。 SymbolTableIndex には、シンボル テーブルへのインデックスではなく、変位が含まれています。 |
| IMAGE_REL_PPC_SECRELLO |
0x0013 |
セクションの先頭からのターゲットの 32 ビット オフセットの下位 16 ビット。 |
| IMAGE_REL_PPC_GPREL |
0x0015 |
GP レジスタ相対のターゲットの 16 ビット符号付き変位。 |
| IMAGE_REL_PPC_TOKEN |
0x0016 |
CLR トークン。 |
Intel 386 プロセッサ
Intel 386 および互換性のあるプロセッサでは、次の再配置の種類インジケーターが定義されています。
| 定数 | 値 | 説明 |
|---|---|---|
| IMAGE_REL_I386_ABSOLUTE |
0x0000 |
この再配置は無視されます。 |
| IMAGE_REL_I386_DIR16 |
0x0001 |
サポートされていません。 |
| IMAGE_REL_I386_REL16 |
0x0002 |
サポートされていません。 |
| IMAGE_REL_I386_DIR32 |
0x0006 |
ターゲットの 32 ビット VA。 |
| IMAGE_REL_I386_DIR32NB |
0x0007 |
ターゲットの 32 ビット RVA。 |
| IMAGE_REL_I386_SEG12 |
0x0009 |
サポートされていません。 |
| IMAGE_REL_I386_SECTION |
0x000A |
ターゲットを含むセクションの 16 ビット セクション インデックス。 これは、デバッグ情報をサポートするために使用されます。 |
| IMAGE_REL_I386_SECREL |
0x000B |
セクションの先頭からのターゲットの 32 ビット オフセット。 これは、デバッグ情報と静的スレッド ローカル ストレージをサポートするために使用されます。 |
| IMAGE_REL_I386_TOKEN |
0x000C |
CLR トークン。 |
| IMAGE_REL_I386_SECREL7 |
0x000D |
ターゲットを含むセクションのベースからの 7 ビット オフセット。 |
| IMAGE_REL_I386_REL32 |
0x0014 |
ターゲットに対する 32ビットの相対変位。 これにより、x86 相対ブランチと呼び出し命令がサポートされます。 |
Intel Itanium プロセッサ ファミリ (IPF)
Intel Itanium プロセッサ ファミリおよび互換性のあるプロセッサでは、次の再配置の種類インジケーターが定義されています。 命令の再配置では、再配置オフセットにバンドルのオフセットとスロット番号が使用されることに注意してください。
| 定数 | 値 | 説明 |
|---|---|---|
| IMAGE_REL_IA64_ABSOLUTE |
0x0000 |
この再配置は無視されます。 |
| IMAGE_REL_IA64_IMM14 |
0x0001 |
この命令の再配置の後に ADDEND 再配置を続けることができ、その値は、IMM14 バンドル内の指定されたスロットに挿入される前にターゲット アドレスに追加されます。 再配置ターゲットは絶対であるか、イメージを固定する必要があります。 |
| IMAGE_REL_IA64_IMM22 |
0x0002 |
この命令の再配置の後に ADDEND 再配置を続けることができ、その値は、IMM22 バンドル内の指定されたスロットに挿入される前にターゲット アドレスに追加されます。 再配置ターゲットは絶対であるか、イメージを固定する必要があります。 |
| IMAGE_REL_IA64_IMM64 |
0x0003 |
この再配置のスロット番号は 1 である必要があります。 この再配置の後に ADDEND 再配置を続けることができ、その値は、IMM64 バンドルの 3 つのスロットすべてに格納される前に、ターゲット アドレスに追加されます。 |
| IMAGE_REL_IA64_DIR32 |
0x0004 |
ターゲットの 32 ビット VA。 これは、/LARGEADDRESSAWARE:NO イメージでのみサポートされます。 |
| IMAGE_REL_IA64_DIR64 |
0x0005 |
ターゲットの 64 ビット VA。 |
| IMAGE_REL_IA64_PCREL21B |
0x0006 |
この命令は、16 ビット配置ターゲットに対する 25 ビットの相対変位でフィックスアップされます。 変位の下位 4 ビットは 0 であり、格納されません。 |
| IMAGE_REL_IA64_PCREL21M |
0x0007 |
この命令は、16 ビット配置ターゲットに対する 25 ビットの相対変位でフィックスアップされます。 変位の下位 4 ビットは 0 であり、格納されません。 |
| IMAGE_REL_IA64_PCREL21F |
0x0008 |
この再配置のオフセットの LSB にはスロット番号を含める必要があります。残りはバンドル アドレスです。 このバンドルは、16 ビット配置ターゲットに対する 25 ビットの相対変位でフィックスアップされます。 変位の下位 4 ビットは 0 であり、格納されません。 |
| IMAGE_REL_IA64_GPREL22 |
0x0009 |
この命令の再配置の後に、ターゲット アドレスに値が追加される ADDEND 再配置と、計算されて GPREL22 バンドルに適用される 22 ビットの GP 相対オフセットを指定できます。 |
| IMAGE_REL_IA64_LTOFF22 |
0x000A |
この命令は、ターゲット シンボルのリテラル テーブル エントリに対する 22 ビット GP 相対オフセットでフィックスアップされます。 リンカーは、この再配置と後に続く可能性がある ADDEND 再配置に基づいて、このリテラル テーブル エントリを作成します。 |
| IMAGE_REL_IA64_SECTION |
0x000B |
ターゲットを含むセクションの 16 ビット セクション インデックス。 これは、デバッグ情報をサポートするために使用されます。 |
| IMAGE_REL_IA64_SECREL22 |
0x000C |
この命令は、セクションの先頭からのターゲットの 22 ビット オフセットでフィックスアップされます。 この再配置の直後に ADDEND 再配置を続けることができ、その Value フィールドにはセクションの先頭からのターゲットの 32 ビット符号なしオフセットが含まれます。 |
| IMAGE_REL_IA64_SECREL64I |
0x000D |
この再配置のスロット番号は 1 である必要があります。 この命令は、セクションの先頭からのターゲットの 64 ビット オフセットでフィックスアップされます。 この再配置の直後に ADDEND 再配置を続けることができ、その Value フィールドにはセクションの先頭からのターゲットの 32 ビット符号なしオフセットが含まれます。 |
| IMAGE_REL_IA64_SECREL32 |
0x000E |
セクションの先頭からのターゲットの 32 ビット オフセットでフィックスアップされるデータのアドレス。 |
| IMAGE_REL_IA64_DIR32NB |
0x0010 |
ターゲットの 32 ビット RVA。 |
| IMAGE_REL_IA64_SREL14 |
0x0011 |
これは、再配置可能な 2 つのターゲット間の差を含む符号付き 14 ビットイミディエイトに適用されます。 これは、コンパイラがこの値を既に出力していることを示すリンカーの宣言フィールドです。 |
| IMAGE_REL_IA64_SREL22 |
0x0012 |
これは、再配置可能な 2 つのターゲット間の差を含む符号付き 22 ビットイミディエイトに適用されます。 これは、コンパイラがこの値を既に出力していることを示すリンカーの宣言フィールドです。 |
| IMAGE_REL_IA64_SREL32 |
0x0013 |
これは、再配置可能な 2 つの値の間の差を含む符号付き 32 ビットイミディエイトに適用されます。 これは、コンパイラがこの値を既に出力していることを示すリンカーの宣言フィールドです。 |
| IMAGE_REL_IA64_UREL32 |
0x0014 |
これは、再配置可能な 2 つの値の間の差を含む符号なし 32 ビットイミディエイトに適用されます。 これは、コンパイラがこの値を既に出力していることを示すリンカーの宣言フィールドです。 |
| IMAGE_REL_IA64_PCREL60X |
0x0015 |
MLX バンドルの BRL 命令として常に維持される 60 ビット PC 相対フィックスアップ。 |
| IMAGE_REL_IA64_PCREL60B |
0x0016 |
60 ビット PC 相対フィックスアップ。 ターゲットの変位が符号付き 25 ビット フィールドに収まる場合は、スロット 1 の NOP.B およびスロット 2 の25 ビット BR 命令 (下位 4 ビットがすべて 0 であり、ドロップされる) を使用して、バンドル全体を MBB バンドルに変換します。 |
| IMAGE_REL_IA64_PCREL60F |
0x0017 |
60 ビット PC 相対フィックスアップ。 ターゲットの変位が符号付き 25 ビット フィールドに収まる場合は、スロット 1 の NOP.F およびスロット 2 の25 ビット (下位 4 ビットがすべて 0 であり、ドロップされる) BR 命令を使用して、バンドル全体を MFB バンドルに変換します。 |
| IMAGE_REL_IA64_PCREL60I |
0x0018 |
60 ビット PC 相対フィックスアップ。 ターゲットの変位が符号付き 25 ビット フィールドに収まる場合は、スロット 1 の NOP.I およびスロット 2 の25 ビット (下位 4 ビットがすべて 0 であり、ドロップされる) BR 命令を使用して、バンドル全体を MIB バンドルに変換します。 |
| IMAGE_REL_IA64_PCREL60M |
0x0019 |
60 ビット PC 相対フィックスアップ。 ターゲットの変位が符号付き 25 ビット フィールドに収まる場合は、スロット 1 の NOP.M およびスロット 2 の25 ビット (下位 4 ビットがすべて 0 であり、ドロップされる) BR 命令を使用して、バンドル全体を MMB バンドルに変換します。 |
| IMAGE_REL_IA64_IMMGPREL64 |
0x001a |
64 ビット GP 相対フィックスアップ。 |
| IMAGE_REL_IA64_TOKEN |
0x001b |
CLR トークン。 |
| IMAGE_REL_IA64_GPREL32 |
0x001c |
32 ビット GP 相対フィックスアップ。 |
| IMAGE_REL_IA64_ADDEND |
0x001F |
この再配置は、IMM14、IMM22、IMM64、GPREL22、LTOFF22、LTOFF64、SECREL22、SECREL64I、または SECREL32 再配置のいずれかの直後である場合のみ有効です。 その値には、データではなく、バンドル内の命令に適用される加数が含まれています。 |
MIPS プロセッサ
MIPS プロセッサには、次の再配置の種類インジケーターが定義されています。
| 定数 | 値 | 説明 |
|---|---|---|
| IMAGE_REL_MIPS_ABSOLUTE |
0x0000 |
この再配置は無視されます。 |
| IMAGE_REL_MIPS_REFHALF |
0x0001 |
ターゲットの 32 ビット VA の上位 16 ビット。 |
| IMAGE_REL_MIPS_REFWORD |
0x0002 |
ターゲットの 32 ビット VA。 |
| IMAGE_REL_MIPS_JMPADDR |
0x0003 |
ターゲットの VA の下位 26 ビット。 これにより、MIPS J および JAL 命令がサポートされます。 |
| IMAGE_REL_MIPS_REFHI |
0x0004 |
ターゲットの 32 ビット VA の上位 16 ビット。 これは、完全なアドレスを読み込む 2 命令シーケンスの最初の命令に使用されます。 この再配置の直後に PAIR 再配置が続く必要があります。その SymbolTableIndex には、符号付き 16 ビット変位が含まれており、再配置される位置から取得される上位 16 ビットに追加されます。 |
| IMAGE_REL_MIPS_REFLO |
0x0005 |
ターゲットの VA の下位 16 ビット。 |
| IMAGE_REL_MIPS_GPREL |
0x0006 |
GP レジスタ相対のターゲットの 16 ビット符号付き変位。 |
| IMAGE_REL_MIPS_LITERAL |
0x0007 |
IMAGE_REL_MIPS_GPREL と同じです。 |
| IMAGE_REL_MIPS_SECTION |
0x000A |
ターゲットを含むセクションの 16 ビット セクション インデックス。 これは、デバッグ情報をサポートするために使用されます。 |
| IMAGE_REL_MIPS_SECREL |
0x000B |
セクションの先頭からのターゲットの 32 ビット オフセット。 これは、デバッグ情報と静的スレッド ローカル ストレージをサポートするために使用されます。 |
| IMAGE_REL_MIPS_SECRELLO |
0x000C |
セクションの先頭からのターゲットの 32 ビット オフセットの下位 16 ビット。 |
| IMAGE_REL_MIPS_SECRELHI |
0x000D |
セクションの先頭からのターゲットの 32 ビット オフセットの上位 16 ビット。 IMAGE_REL_MIPS_PAIR再配置は、この直後に続く必要があります。 PAIR 再配置の SymbolTableIndex には、再配置される位置から取得される上位 16 ビットに追加される符号付き 16 ビット変位が含まれています。 |
| IMAGE_REL_MIPS_JMPADDR16 |
0x0010 |
ターゲットの VA の下位 26 ビット。 これにより、MIPS16 JAL 命令がサポートされます。 |
| IMAGE_REL_MIPS_REFWORDNB |
0x0022 |
ターゲットの 32 ビット RVA。 |
| IMAGE_REL_MIPS_PAIR |
0x0025 |
この再配置は、REFHI または SECRELHI 再配置の直後である場合のみ有効です。 SymbolTableIndex には、シンボル テーブルへのインデックスではなく、変位が含まれています。 |
Mitsubishi M32R
Mitsubishi M32R プロセッサには、次の再配置の種類インジケーターが定義されています。
| 定数 | 値 | 説明 |
|---|---|---|
| IMAGE_REL_M32R_ABSOLUTE |
0x0000 |
この再配置は無視されます。 |
| IMAGE_REL_M32R_ADDR32 |
0x0001 |
ターゲットの 32 ビット VA。 |
| IMAGE_REL_M32R_ADDR32NB |
0x0002 |
ターゲットの 32 ビット RVA。 |
| IMAGE_REL_M32R_ADDR24 |
0x0003 |
ターゲットの 24 ビット VA。 |
| IMAGE_REL_M32R_GPREL16 |
0x0004 |
ターゲットの GP レジスタからの 16 ビット オフセット。 |
| IMAGE_REL_M32R_PCREL24 |
0x0005 |
プログラム カウンター (PC) からのターゲットの 24 ビット オフセット。2 ビット左にシフトされ、符号拡張されています |
| IMAGE_REL_M32R_PCREL16 |
0x0006 |
プログラム カウンター (PC) からのターゲットの 16 ビット オフセット。2 ビット左にシフトされ、符号拡張されています |
| IMAGE_REL_M32R_PCREL8 |
0x0007 |
プログラム カウンター (PC) からのターゲットの 8 ビット オフセット。2 ビット左にシフトされ、符号拡張されています |
| IMAGE_REL_M32R_REFHALF |
0x0008 |
ターゲット VA の 16 MSB。 |
| IMAGE_REL_M32R_REFHI |
0x0009 |
LSB 符号拡張用に調整された、ターゲット VA の 16 MSB。 完全な 32 ビット アドレスを読み込む 2 命令シーケンスの最初の命令に使用されます。 この再配置の直後に PAIR 再配置が続く必要があります。その SymbolTableIndex には、符号付き 16 ビット変位が含まれており、再配置される位置から取得される上位 16 ビットに追加されます。 |
| IMAGE_REL_M32R_REFLO |
0x000A |
ターゲット VA の 16 LSB。 |
| IMAGE_REL_M32R_PAIR |
0x000B |
この再配置は、REFHI 再配置に続ける必要があります。 SymbolTableIndex には、シンボル テーブルへのインデックスではなく、変位が含まれています。 |
| IMAGE_REL_M32R_SECTION |
0x000C |
ターゲットを含むセクションの 16 ビット セクション インデックス。 これは、デバッグ情報をサポートするために使用されます。 |
| IMAGE_REL_M32R_SECREL |
0x000D |
セクションの先頭からのターゲットの 32 ビット オフセット。 これは、デバッグ情報と静的スレッド ローカル ストレージをサポートするために使用されます。 |
| IMAGE_REL_M32R_TOKEN |
0x000E |
CLR トークン。 |
COFF 行番号 (非推奨)
COFF 行番号は生成されなくなりました。今後は使用されなくなります。
COFF 行番号は、ソース ファイル内のコードと行番号のリレーションシップを示します。 COFF 行番号の Microsoft 形式は標準の COFF に似ていますが、1 つのセクションを複数のソース ファイル内の行番号に関連付けることができるように拡張されています。
COFF 行番号は、固定長レコードの配列で構成されます。 配列の位置 (ファイル オフセット) とサイズは、セクション ヘッダーで指定されます。 各行番号レコードの形式は次のとおりです。
| Offset | サイズ | フィールド | 説明 |
|---|---|---|---|
| 0 |
4 |
Type (*) |
これは、SymbolTableIndex と VirtualAddress という 2 つのフィールドの共用体です。 SymbolTableIndex と RVA のどちらを使用するかは、Linenumber の値によって異なります。 |
| 4 |
2 |
Linenumber |
0 以外の場合、このフィールドは 1 から始まる行番号を指定します。 0 の場合、Type フィールドは関数のシンボル テーブル インデックスとして解釈されます。 |
Type フィールドは、SymbolTableIndex と VirtualAddress という 2 つの 4 バイト フィールドの共用体です。
| Offset | サイズ | フィールド | 説明 |
|---|---|---|---|
| 0 |
4 |
SymbolTableIndex |
Linenumber が 0 の場合に使用されます。関数のテーブル エントリをシンボル化するためのインデックスです。 この形式は、行番号レコードのグループが参照する関数を示すために使用されます。 |
| 0 |
4 |
VirtualAddress |
Linenumber が 0 以外の場合に使用されます。指定されたソース行に対応する実行可能コードの RVA です。 オブジェクト ファイルでは、これにはセクション内の VA が含まれます。 |
行番号レコードは、Linenumber フィールドを 0 に設定してシンボル テーブルの関数定義を指すようにするか、オブジェクト コードで正の整数 (行番号) および対応するアドレスを指定して標準の行番号エントリとして機能させることができます。
行番号エントリのグループは、常に最初の形式である関数シンボルのインデックスで始まります。 これがセクション内の最初の行番号レコードである場合、セクションの COMDAT フラグが設定されていれば、関数の COMDAT シンボル名でもあります。 「COMDAT セクション (オブジェクトのみ)」を参照してください。 シンボル テーブル内の関数の補助レコードには、この同じ行番号レコードを指す Linenumber フィールドへのポインターがあります。
関数を識別するレコードの後に、実際の行番号情報を提供する任意の数の行番号エントリ (つまり、Linenumber が 0 より大きいエントリ) が続きます。 これらのエントリは、関数の先頭を基準にして 1 から始まり、最初の行を除く関数内のすべてのソース行を表します。
たとえば、次の例の最初の行番号レコードでは、ReverseSign 関数 (ReverseSign の SymbolTableIndex、Linenumber を 0 に設定) を指定します。 そのあとに、次に示すようにソース行に対応する Linenumber 値が 1、2、3 のレコードが続きます。
// some code precedes ReverseSign function
int ReverseSign(int i)
1: {
2: return -1 * i;
3: }
COFF シンボル テーブル
このセクションのシンボル テーブルは、従来の COFF 形式から継承されるものです。 Microsoft Visual C++ のデバッグ情報とは異なります。 1 つのファイルに COFF シンボル テーブルと Visual C++ デバッグ情報の両方を含めることができ、この 2 つは別々に保持されます。 一部の Microsoft ツールでは、リンカーに COMDAT 情報を伝達するなど、限られた重要な目的のためにシンボル テーブルが使用されます。 セクション名とファイル名、およびコードとデータ シンボルがシンボル テーブルにリストされます。
シンボル テーブルの場所は COFF ヘッダーに示されます。
シンボル テーブルは、それぞれ 18 バイトの長さのレコードの配列です。 各レコードは、標準または補助のシンボル テーブル レコードです。 標準レコードは、シンボルまたは名前を定義し、形式は次のとおりです。
| Offset | サイズ | フィールド | 説明 |
|---|---|---|---|
| 0 |
8 |
Name (*) |
3 つの構造体の共用体で表されるシンボルの名前。 名前の長さが 8 バイト以下の場合は、8 バイトの配列が使用されます。 詳細については、「シンボル名の表現」を参照してください。 |
| 8 |
4 |
値 |
シンボルに関連付けられた値。 このフィールドの解釈は、SectionNumber と StorageClass によって異なります。 一般的な意味は、再配置可能なアドレスです。 |
| 12 |
2 |
SectionNumber |
セクション テーブルへの 1 から始まるインデックスを使用してセクションを識別する符号付き整数。 セクション 5.4.2「セクション番号値」で定義されているように、一部の値は特別な意味を持ちます。 |
| 14 |
2 |
Type |
型を表す数値。 Microsoft ツールでは、このフィールドが 0x20 (関数) または0x0 (関数以外) に設定されます。 詳細については、「型の表現」を参照してください。 |
| 16 |
1 |
StorageClass |
ストレージ クラスを表す列挙値。 詳細については、「ストレージ クラス」を参照してください。 |
| 17 |
1 |
NumberOfAuxSymbols |
このレコードに続く補助シンボル テーブル エントリの数。 |
0 個以上の補助シンボル テーブル レコードが、各標準シンボル テーブル レコードの直後に続きます。 ただし、通常、標準のシンボル テーブル レコードに続く補助シンボル テーブル レコードは 1 つです (長いファイル名を持つ .file レコードを除く)。 各補助レコードは、標準シンボル テーブル レコードと同じサイズ (18 バイト) ですが、新しいシンボルを定義するのではなく、補助レコードは最後に定義されたシンボルに関する追加情報を提供します。 複数の形式のうちどれを使用するかは、StorageClass フィールドによって決まります。 補助シンボル テーブル レコード用に現在定義されている形式は、セクション 5.5「補助シンボル レコード」に示されています。
COFF シンボル テーブルを読み取るツールでは、解釈が不明な補助シンボル レコードを無視する必要があります。 これにより、既存のツールを損なうことなく、シンボル テーブルの形式を拡張して新しい補助レコードを追加できます。
シンボル名の表現
長さが 8 バイト以下の場合、シンボル テーブルの ShortName フィールドは名前自体を含む 8 バイトで構成されます。そうでない場合は、ShortName フィールドは文字列テーブルへのオフセットを提供します。 名前自体、またはオフセットが提供されているかを判断するには、最初の 4 バイトが 0 に等しいかどうかをテストします。
規則により、名前は 0 で終わる UTF-8 エンコード文字列として扱われます。
| Offset | サイズ | フィールド | 説明 |
|---|---|---|---|
| 0 |
8 |
ShortName |
8 バイトの配列。 名前の長さが 8 バイト未満の場合、この配列の右側に null が埋め込まれます。 |
| 0 |
4 |
Zeroes |
名前が 8 バイトを超える場合にすべて 0 に設定されるフィールド。 |
| 4 |
4 |
Offset |
文字列テーブルへのオフセット。 |
セクション番号の値
通常、シンボル テーブル エントリの Section Value フィールドは、セクション テーブルへの 1 から始まるインデックスです。 ただし、このフィールドは符号付き整数であり、負の値を受け取ることができます。 次の 1 未満の値は特別な意味を持ちます。
| 定数 | 値 | 説明 |
|---|---|---|
| IMAGE_SYM_UNDEFINED |
0 |
シンボル レコードにはセクションがまだ割り当てられていません。 0 の値は、外部シンボルへの参照が他の場所で定義されていることを示します。 0 以外の値は、値によって指定されるサイズの共通シンボルです。 |
| IMAGE_SYM_ABSOLUTE |
-1 |
シンボルには絶対値 (再配置不可) があり、アドレスではありません。 |
| IMAGE_SYM_DEBUG |
-2 |
シンボルは、一般的な型またはデバッグ情報を提供しますが、セクションには対応していません。 Microsoft ツールでは、この設定を .file レコード (ストレージ クラス FILE) と共に使用します。 |
型の表現
シンボル テーブル エントリの Type フィールドには 2 バイトが含まれており、各バイトは型情報を表します。 LSB は単純な (基本) データ型を表し、MSB は複合型 (存在する場合) を表します。
| MSB | LSB |
|---|---|
| 複合型: なし、ポインター、関数、配列。 |
基本型: 整数、浮動小数点など。 |
基本型には次の値が定義されていますが、通常 Microsoft ツールではこのフィールドは使用されず、LSB は 0 に設定されます。 代わりに、Visual C++ デバッグ情報を使用して型が示されます。 ただし、万全を期して使用可能な COFF 値をこちらに示します。
| 定数 | 値 | 説明 |
|---|---|---|
| IMAGE_SYM_TYPE_NULL |
0 |
型情報がないか、未知の基本型。 Microsoft ツールではこの設定が使用されます |
| IMAGE_SYM_TYPE_VOID |
1 |
有効な型ではありません。void ポインターおよび関数で使用されます |
| IMAGE_SYM_TYPE_CHAR |
2 |
文字 (符号付きバイト) |
| IMAGE_SYM_TYPE_SHORT |
3 |
2 バイトの符号付き整数 |
| IMAGE_SYM_TYPE_INT |
4 |
自然な整数型 (Windows では通常 4 バイト) |
| IMAGE_SYM_TYPE_LONG |
5 |
4 バイトの符号付き整数 |
| IMAGE_SYM_TYPE_FLOAT |
6 |
4 バイトの浮動小数点数 |
| IMAGE_SYM_TYPE_DOUBLE |
7 |
8 バイトの浮動小数点数 |
| IMAGE_SYM_TYPE_STRUCT |
8 |
構造体 |
| IMAGE_SYM_TYPE_UNION |
9 |
共用体 |
| IMAGE_SYM_TYPE_ENUM |
10 |
列挙型 |
| IMAGE_SYM_TYPE_MOE |
11 |
列挙メンバー (特定の値) |
| IMAGE_SYM_TYPE_BYTE |
12 |
バイト。1 バイトの符号なし整数 |
| IMAGE_SYM_TYPE_WORD |
13 |
単語。2 バイトの符号なし整数 |
| IMAGE_SYM_TYPE_UINT |
14 |
自然サイズの符号なし整数 (通常は 4 バイト) |
| IMAGE_SYM_TYPE_DWORD |
15 |
4 バイトの符号なし整数。 |
最上位バイトは、LSB で指定された基本型について、シンボルがそれを指すポインター、それを返す関数、またはその配列であるかどうかを指定します。 Microsoft ツールでは、シンボルが関数であるかどうかを示すためだけにこのフィールドを使用します。そのため、結果として得られる Type フィールドの値は、0x0 と 0x20 の 2 つだけです。 ただし、他のツールでは、このフィールドを使用してより多くの情報をやり取りできます。
関数の属性を正しく指定することは非常に重要です。 この情報は、インクリメンタル リンクが正しく機能するために必要不可欠です。 一部のアーキテクチャでは、他の目的で情報が必要になる場合があります。
| 定数 | 値 | 説明 |
|---|---|---|
| IMAGE_SYM_DTYPE_NULL |
0 |
派生型はありません。シンボルは単純なスカラー変数です。 |
| IMAGE_SYM_DTYPE_POINTER |
1 |
シンボルは基本型へのポインターです。 |
| IMAGE_SYM_DTYPE_FUNCTION |
2 |
シンボルは基本型を返す関数です。 |
| IMAGE_SYM_DTYPE_ARRAY |
3 |
シンボルは基本型の配列です。 |
ストレージ クラス
シンボル テーブルの StorageClass フィールドは、シンボルが表す定義の種類を示します。 以下の表に、使用可能な値を示します。 StorageClass フィールドは1 バイトの符号なし整数であることに注意してください。 したがって、特別な値である -1 は、符号なしの等価の値である 0xFF を表すために使用できます。
従来の COFF 形式では多くのストレージ クラス値が使用されますが、Microsoft ツールではほとんどのシンボル情報に Visual C++ デバッグ形式が使用され、一般に、EXTERNAL (2)、STATIC (3)、FUNCTION (101)、FILE (103) の 4 つのストレージ クラス値だけが使用されます。 以下の 2 番目の列見出しを除き、"Value" はシンボル レコードの Value フィールドを意味するために使用されます (その解釈はストレージ クラスとして見つかった数値によって異なります)。
| 定数 | 値 | Value フィールドの説明/解釈 |
|---|---|---|
| IMAGE_SYM_CLASS_END_OF_FUNCTION |
-1 (0xFF) |
デバッグ目的で関数の終了を表す特別なシンボル。 |
| IMAGE_SYM_CLASS_NULL |
0 |
ストレージ クラスが割り当てられていません。 |
| IMAGE_SYM_CLASS_AUTOMATIC |
1 |
自動 (スタック) 変数。 Value フィールドは、スタック フレームのオフセットを指定します。 |
| IMAGE_SYM_CLASS_EXTERNAL |
2 |
Microsoft ツールによって外部シンボルに使用される値。 Value フィールドは、セクション番号が IMAGE_SYM_UNDEFINED (0) の場合にサイズを示します。 セクション番号が 0 でない場合、Value フィールドはセクション内のオフセットを指定します。 |
| IMAGE_SYM_CLASS_STATIC |
3 |
セクション内のシンボルのオフセット。 Value フィールドが 0 の場合、このシンボルはセクション名を表します。 |
| IMAGE_SYM_CLASS_REGISTER |
4 |
レジスタ変数。 Value フィールドはレジスタ番号を指定します。 |
| IMAGE_SYM_CLASS_EXTERNAL_DEF |
5 |
外部で定義されているシンボル。 |
| IMAGE_SYM_CLASS_LABEL |
6 |
モジュール内で定義されているコード ラベル。 Value フィールドは、セクション内のシンボルのオフセットを指定します。 |
| IMAGE_SYM_CLASS_UNDEFINED_LABEL |
7 |
定義されていないコード ラベルへの参照。 |
| IMAGE_SYM_CLASS_MEMBER_OF_STRUCT |
8 |
構造体メンバー。 Value フィールドは、n 番目のメンバーを指定します。 |
| IMAGE_SYM_CLASS_ARGUMENT |
9 |
関数の仮引数 (パラメーター)。 Value フィールドは、n 番目の引数を指定します。 |
| IMAGE_SYM_CLASS_STRUCT_TAG |
10 |
構造体タグ名エントリ。 |
| IMAGE_SYM_CLASS_MEMBER_OF_UNION |
11 |
共用体メンバー。 Value フィールドは、n 番目のメンバーを指定します。 |
| IMAGE_SYM_CLASS_UNION_TAG |
12 |
共用体タグ名エントリ。 |
| IMAGE_SYM_CLASS_TYPE_DEFINITION |
13 |
Typedef エントリ。 |
| IMAGE_SYM_CLASS_UNDEFINED_STATIC |
14 |
静的データ宣言。 |
| IMAGE_SYM_CLASS_ENUM_TAG |
15 |
列挙型の tagname エントリ。 |
| IMAGE_SYM_CLASS_MEMBER_OF_ENUM |
16 |
列挙メンバー。 Value フィールドは、n 番目のメンバーを指定します。 |
| IMAGE_SYM_CLASS_REGISTER_PARAM |
17 |
レジスタ パラメーター。 |
| IMAGE_SYM_CLASS_BIT_FIELD |
18 |
ビット フィールド参照。 Value フィールドは、ビット フィールドの n 番目のビットを指定します。 |
| IMAGE_SYM_CLASS_BLOCK |
100 |
.bb (ブロックの開始) または .eb (ブロックの終了) レコード。 Value フィールドは、コード位置の再配置可能アドレスです。 |
| IMAGE_SYM_CLASS_FUNCTION |
101 |
関数の範囲を定義するシンボル レコード用に Microsoft ツールで使用される値です。関数の開始 (.bf)、関数の終了 (.ef)、関数内の行数 (.lf) があります。 .lf レコードの場合、Value フィールドは関数内のソース行の数を示します。 .ef レコードの場合、Value フィールドは関数コードのサイズを示します。 |
| IMAGE_SYM_CLASS_END_OF_STRUCT |
102 |
構造体の終わりのエントリ。 |
| IMAGE_SYM_CLASS_FILE |
103 |
Microsoft ツールおよび従来の COFF 形式で、ソース ファイルシンボル レコードに使用される値。 シンボルの後に、ファイルに名前を付ける補助レコードが続きます。 |
| IMAGE_SYM_CLASS_SECTION |
104 |
セクションの定義 (Microsoft ツールでは、代わりに STATIC ストレージ クラスが使用されます)。 |
| IMAGE_SYM_CLASS_WEAK_EXTERNAL |
105 |
弱い外部。 詳細については、「補助形式 3: 弱い外部」を参照してください。 |
| IMAGE_SYM_CLASS_CLR_TOKEN |
107 |
CLR トークン シンボル。 この名前は、トークンの 16 進数値で構成される ASCII 文字列です。 詳細については、「CLR トークン定義 (オブジェクトのみ)」を参照してください。 |
補助シンボル レコード
補助シンボル テーブル レコードは常に何らかの標準シンボル テーブル レコードに続き、適用されます。 補助レコードには、ツールで認識できる任意の形式を指定できますが、シンボル テーブルが通常のサイズの配列として維持されるように、18 バイトを割り当てる必要があります。 現在、Microsoft ツールでは、関数定義、関数の開始および終了シンボル (.bf および .ef)、弱い外部、ファイル名、セクション定義のレコードの補助形式が認識されます。
従来の COFF 設計には、配列と構造体の補助レコード形式も含まれています。 Microsoft ツールではこれらは使用されません。代わりに、そのシンボル情報を Visual C++ デバッグ形式でデバッグ セクションに配置します。
補助形式 1: 関数定義
シンボル テーブル レコードでは、EXTERNAL (2) のストレージ クラス、関数 (0x20) であることを示す Type 値、および 0 より大きいセクション番号がすべて含まれている場合に関数定義の先頭がマークされます。 UNDEFINED (0) のセクション番号を持つシンボル テーブル レコードは、関数を定義せず、補助レコードもないことに注意してください。 関数定義シンボル レコードの後に、下に示す形式の補助レコードが続きます。
| Offset | サイズ | フィールド | 説明 |
|---|---|---|---|
| 0 |
4 |
TagIndex |
対応する .bf (関数の開始) シンボル レコードのシンボル テーブル インデックス。 |
| 4 |
4 |
TotalSize |
関数自体の実行可能コードのサイズ。 関数がそれ自体のセクション内にある場合、配置を考慮により、セクション ヘッダーの SizeOfRawData がこのフィールド以上になります。 |
| 8 |
4 |
PointerToLinenumber |
関数の最初の COFF 行番号エントリのファイル オフセット。存在しない場合は 0。 詳細については、「COFF 行番号 (非推奨)」を参照してください。 |
| 12 |
4 |
PointerToNextFunction |
次の関数用のレコードのシンボル テーブル インデックス。 関数がシンボル テーブルの最後である場合、このフィールドは 0 に設定されます。 |
| 16 |
2 |
未使用 |
補助形式 2: .bf および .ef シンボル
シンボル テーブル内の関数定義ごとに、開始、終了、行数が 3 つの項目で記述されます。 これらの各シンボルには、ストレージ クラス FUNCTION (101) があります。
.bf (関数の開始) という名前のシンボル レコード。 Value フィールドは未使用です。
.lf という名前のシンボル レコード (関数内の行数)。 Value フィールドには、関数内の行数が示されます。
.ef (関数の終わり) という名前のシンボル レコード。 Value フィールドの数値は、関数定義シンボル レコードの Total Size フィールドと同じです。
.bf および .ef シンボル レコード (.lf レコードではない) の後に、次の形式の補助レコードが続きます。
| Offset | サイズ | フィールド | 説明 |
|---|---|---|---|
| 0 |
4 |
未使用 |
|
| 4 |
2 |
Linenumber |
.bf または .ef レコードに対応するソース ファイル内の実際の順序の行番号 (1、2、3 など)。 |
| 6 |
6 |
未使用 |
|
| 12 |
4 |
PointerToNextFunction (.bf のみ) |
次の .bf シンボル レコードのシンボル テーブル インデックス。 関数がシンボル テーブルの最後である場合、このフィールドは 0 に設定されます。 .ef レコードには使用されません。 |
| 16 |
2 |
未使用 |
補助形式 3: 弱い外部
"弱い外部" は、リンク時に柔軟性を持たせるためのオブジェクト ファイルのメカニズムです。 モジュールには未解決の外部シンボル (sym1) が含まれる場合がありますが、sym1 がリンク時に存在しない場合は、代わりに別の外部シンボル (sym2) を使用して参照を解決することを示す補助レコードを含めることもできます。
sym1 の定義がリンクされている場合、シンボルへの外部参照は正常に解決されます。 sym1 の定義がリンクされていない場合、sym1 の弱い外部へのすべての参照は代わりに sym2 を参照します。 外部シンボル sym2 は常にリンクする必要があります。通常は、sym1 への弱い参照を含むモジュールで定義されます。
弱い外部は、EXTERNAL ストレージ クラス、UNDEF セクション番号、および 0 の値を持つシンボル テーブル レコードによって表されます。 弱い外部シンボル レコードの後に、次の形式の補助レコードが続きます。
| Offset | サイズ | フィールド | 説明 |
|---|---|---|---|
| 0 |
4 |
TagIndex |
sym1 が見つからない場合にリンクするシンボルである sym2 のシンボル テーブル インデックス。 |
| 4 |
4 |
特性 |
IMAGE_WEAK_EXTERN_SEARCH_NOLIBRARY の値は、sym1 のライブラリ検索を実行する必要がないことを示します。 IMAGE_WEAK_EXTERN_SEARCH_LIBRARY の値は、sym1 のライブラリ検索を実行する必要があることを示します。 IMAGE_WEAK_EXTERN_SEARCH_ALIAS の値は、sym1 が sym2 のエイリアスであることを示します。 |
| 8 |
10 |
未使用 |
Characteristics フィールドは WINNT.H で定義されないことに注意してください。代わりに、Total Size フィールドが使用されます。
補助形式 4: ファイル
この形式は、ストレージ クラスが FILE (103) のシンボル テーブル レコードの後に続きます。 シンボル名自体は .file にする必要があり、その後に続く補助レコードがソース コード ファイルの名前を指定します。
| Offset | サイズ | フィールド | 説明 |
|---|---|---|---|
| 0 |
18 |
ファイル名 |
ソース ファイルの名前を指定する ANSI 文字列。 最大長より短い場合は null が埋め込まれます。 |
補助形式 5: セクション定義
この形式は、セクションを定義するシンボル テーブル レコードの後に続きます。 このようなレコードには、セクションの名前 (.text や .drectve など) であるシンボル名があり、ストレージ クラスは STATIC (3) です。 補助レコードは、参照するセクションに関する情報を提供します。 したがって、セクション ヘッダーの情報の一部が複製されます。
| Offset | サイズ | フィールド | 説明 |
|---|---|---|---|
| 0 |
4 |
長さ |
セクション データのサイズ。セクション ヘッダーの SizeOfRawData と同じです。 |
| 4 |
2 |
NumberOfRelocations |
セクションの再配置エントリの数。 |
| 6 |
2 |
NumberOfLinenumbers |
セクションの行番号エントリの数。 |
| 8 |
4 |
CheckSum |
共有データのチェックサム。 セクション ヘッダーで IMAGE_SCN_LNK_COMDAT フラグが設定されている場合に適用されます。 詳細については、「COMDAT セクション (オブジェクトのみ)」を参照してください。 |
| 12 |
2 |
数値 |
関連付けられたセクションのセクション テーブルへの 1 から始まるインデックス。 これは、COMDAT の選択設定が 5 の場合に使用されます。 |
| 14 |
1 |
[選択] |
COMDAT 選択番号。 これは、セクションが COMDAT セクションの場合に適用されます。 |
| 15 |
3 |
未使用 |
COMDAT セクション (オブジェクトのみ)
セクション定義補助形式の Selection フィールドは、セクションが COMDAT セクションの場合に適用されます。 COMDAT セクションは、複数のオブジェクト ファイルで定義できるセクションです。 (フラグ IMAGE_SCN_LNK_COMDAT は、セクション ヘッダーの Section Flags フィールドで設定されます)。Selection フィールドによって、リンカーが COMDAT セクションの複数の定義を解決する方法が決定されます。
COMDAT セクションのセクション値を持つ最初のシンボルは、セクション シンボルである必要があります。 このシンボルには、セクションの名前、0 に等しい Value フィールド、対象の COMDAT セクションのセクション番号、IMAGE_SYM_TYPE_NULL と等しい Type フィールド、IMAGE_SYM_CLASS_STATIC と等しい Class フィールド、および 1 つの補助レコードがあります。 2 番目のシンボルは "COMDAT シンボル" と呼ばれ、リンカーによって Selection フィールドと組み合わせて使用されます。
Selection フィールドの値は下のとおりです。
| 定数 | 値 | 説明 |
|---|---|---|
| IMAGE_COMDAT_SELECT_NODUPLICATES |
1 |
このシンボルが既に定義されている場合、リンカーは "複数定義シンボル" エラーを発行します。 |
| IMAGE_COMDAT_SELECT_ANY |
2 |
同じ COMDAT シンボルを定義する任意のセクションをリンクできます。残りは削除されます。 |
| IMAGE_COMDAT_SELECT_SAME_SIZE |
3 |
リンカーは、このシンボルの定義の中から任意のセクションを選択します。 すべての定義が同じサイズでない場合は、"複数定義シンボル" エラーが発行されます。 |
| IMAGE_COMDAT_SELECT_EXACT_MATCH |
4 |
リンカーは、このシンボルの定義の中から任意のセクションを選択します。 すべての定義が完全に一致しない場合は、"複数定義シンボル" エラーが発行されます。 |
| IMAGE_COMDAT_SELECT_ASSOCIATIVE |
5 |
このセクションは、特定の別の COMDAT セクションがリンクされている場合にリンクされます。 この別のセクションは、セクション定義の補助シンボル レコードの Number フィールドで示されます。 この設定は、複数のセクションにコンポーネントがある (たとえば、1 つのセクションにコードがあり、別のセクションにデータある) が、すべてをセットとしてリンクまたは破棄する必要がある場合に便利です。 このセクションに関連付けられる別のセクションは、COMDAT セクションである必要があります。これは、別の関連 COMDAT セクションの場合があります。 関連 COMDAT セクションのセクション関連付けチェーンはループを形成できません。 セクション関連付けチェーンは、IMAGE_COMDAT_SELECT_ASSOCIATIVE が設定されていない COMDAT セクションで終わる必要があります。 |
| IMAGE_COMDAT_SELECT_LARGEST |
6 |
リンカーは、このシンボルのすべての定義の中から最大の定義を選択します。 複数の定義がこのサイズである場合、その選択は任意です。 |
CLR トークン定義 (オブジェクトのみ)
この補助シンボルは通常、IMAGE_SYM_CLASS_CLR_TOKEN の後に続きます。 トークンを COFF シンボル テーブルの名前空間に関連付けるために使用されます。
| Offset | サイズ | フィールド | 説明 |
|---|---|---|---|
| 0 |
1 |
bAuxType |
IMAGE_AUX_SYMBOL_TYPE_TOKEN_DEF (1) である必要があります。 |
| 1 |
1 |
bReserved |
予約済み。0 である必要があります。 |
| 2 |
4 |
SymbolTableIndex |
この CLR トークン定義が参照する COFF シンボルのシンボル インデックス。 |
| 6 |
12 |
予約済み。0 である必要があります。 |
COFF 文字列テーブル
COFF シンボル テーブルの直後に続くのは、COFF 文字列テーブルです。 このテーブルの位置を得るには、COFF ヘッダーのシンボル テーブル アドレスを取得し、それにシンボルの数とシンボルのサイズを乗算した値を加算します。
COFF 文字列テーブルの先頭は、文字列テーブルの残りの部分の合計サイズ (バイト単位) を含む 4 バイトです。 このサイズにはサイズ フィールド自体が含まれるため、文字列が存在しない場合、この場所の値は 4 になります。
サイズの後に続くのは、COFF シンボル テーブル内のシンボルによって指し示される null で終わる文字列です。
属性証明書テーブル (イメージのみ)
属性証明書テーブルを追加すると、属性証明書をイメージに関連付けることができます。 属性証明書テーブルは、クアッドワードに配置された連続する属性証明書エントリのセットで構成されます。 この配置を実現するために、元のファイルの末尾と属性証明書テーブルの先頭の間に 0 の埋め込みが挿入されます。 各属性証明書エントリには、次のフィールドが含まれています。
| Offset | サイズ | フィールド | 説明 |
|---|---|---|---|
| 0 |
4 |
dwLength |
属性証明書エントリの長さを指定します。 |
| 4 |
2 |
wRevision |
証明書のバージョン番号が含まれます。 詳細については、以下の説明を参照してください。 |
| 6 |
2 |
wCertificateType |
bCertificate の内容の種類を指定します。 詳細については、以下の説明を参照してください。 |
| 8 |
参考資料 |
bCertificate |
Authenticode 署名などの証明書が含まれます。 詳細については、以下の説明を参照してください。 |
オプションのヘッダー データ ディレクトリの証明書テーブル エントリの仮想アドレス値は、最初の属性証明書エントリへのファイル オフセットです。 後続のエントリにアクセスするには、現在の属性証明書エントリの先頭から、そのエントリの dwLength バイトを 8 バイトの倍数に切り上げて進みます。 これを、切り上げられた dwLength 値の合計がオプションのヘッダー データ ディレクトリの証明書テーブル エントリの Size 値と等しくなるまで続けます。 切り上げられた dwLength 値の合計が Size 値と等しくない場合は、属性証明書テーブルまたは Size フィールドのいずれかが破損しています。
たとえば、オプションのヘッダー データ ディレクトリの証明書テーブル エントリに以下が含まれるとします。
virtual address = 0x5000
size = 0x1000
最初の証明書は、ディスク上のファイルの先頭からのオフセット 0x5000 で開始します。 すべての属性証明書エントリを進むには、次のようにします。
- 最初の属性証明書の dwLength 値を開始オフセットに加算します。
- 手順 1 の値を最も近い 8 バイトの倍数に切り上げ、2 番目の属性証明書エントリのオフセットを見つけます。
- 手順 2 のオフセット値を 2 番目の属性証明書エントリの dwLength 値に加算し、最も近い 8 バイトの倍数に切り上げて、3 番目の属性証明書エントリのオフセットを特定します。
- 計算したオフセットが 0x6000 (0x5000 開始 + 0x1000 合計サイズ) になるまで、以降の証明書ごとに手順 3 を繰り返します。これで、テーブル全体にアクセスしたことになります。
または、Win32 ImageEnumerateCertificates 関数をループで呼び出して、証明書エントリを列挙することもできます。 関数の参照ページへのリンクについては、「リファレンス」を参照してください。
属性証明書テーブルのエントリには、エントリに正しい dwLength 値、一意の wRevision 値、および一意の wCertificateType 値がある限り、任意の証明書の種類を含めることができます。 証明書テーブル エントリの最も一般的な種類は、wintrust.h に記載されている WIN_CERTIFICATE 構造体です。これについては、このセクションの残りの部分で説明します。
WIN_CERTIFICATE wRevision メンバーのオプションには、次のものが含まれます (ただし、これらに限定されません)。
| 値 | 名前 | Notes |
|---|---|---|
| 0x0100 |
WIN_CERT_REVISION_1_0 |
バージョン 1、Win_Certificate 構造体のレガシ バージョン。 レガシ Authenticode 署名を検証する目的でのみサポートされています |
| 0x0200 |
WIN_CERT_REVISION_2_0 |
バージョン 2 は、Win_Certificate 構造体の現在のバージョンです。 |
WIN_CERTIFICATE wCertificateType メンバーのオプションには、次の表の項目が含まれます (ただし、これらに限定されません)。 一部の値は現在サポートされていないことに注意してください。
| 値 | 名前 | Notes |
|---|---|---|
| 0x0001 |
WIN_CERT_TYPE_X509 |
bCertificate に X.509 証明書が含まれています サポートされていません |
| 0x0002 |
WIN_CERT_TYPE_PKCS_SIGNED_DATA |
bCertificate に PKCS#7 SignedData 構造体が含まれています |
| 0x0003 |
WIN_CERT_TYPE_RESERVED_1 |
予約済み |
| 0x0004 |
WIN_CERT_TYPE_TS_STACK_SIGNED |
ターミナル サーバー プロトコル スタック証明書の署名 サポートされていません |
WIN_CERTIFICATE 構造体の bCertificate メンバーには、wCertificateType で指定されたコンテンツの種類を持つ可変長バイト配列が含まれています。 Authenticode でサポートされる種類は、PKCS#7 SignedData 構造体の WIN_CERT_TYPE_PKCS_SIGNED_DATA です。 Authenticode デジタル署名形式の詳細については、「Windows Authenticode の移植可能な実行可能署名形式」を参照してください。
bCertificate コンテンツがクアッドワード境界で終わらない場合、属性証明書エントリには、bCertificate の末尾から次のクアッドワード境界まで 0 が埋め込まれます。
dwLength 値は、ファイナライズされたWIN_CERTIFICATE 構造体の長さであり、次のように計算されます。
dwLength = offsetof(WIN_CERTIFICATE, bCertificate) + (size of the variable-length binary array contained within bCertificate)
この長さには、各 WIN_CERTIFICATE 構造体がクアッドワードに配置されるという要件を満たすために使用される埋め込みのサイズを含める必要があります。
dwLength += (8 - (dwLength & 7)) & 7;
オプションのヘッダー データ ディレクトリ (イメージのみ) の証明書テーブル エントリで指定された証明書テーブルのサイズには、埋め込みが含まれています。
ImageHlp API を使用して PE ファイルの証明書を列挙、追加、削除する方法の詳細については、「ImageHlp 関数」を参照してください。
証明書データ
前のセクションで説明したように、属性証明書テーブルの証明書には任意の証明書の種類を含めることができます。 PE ファイルの整合性を保証する証明書には、PE イメージ ハッシュが含まれる場合があります。
PE イメージ ハッシュ (またはファイル ハッシュ) は、ハッシュ アルゴリズムによってファイルの整合性に関連するメッセージ ダイジェストが生成されるという点で、ファイル チェックサムに似ています。 ただし、チェックサムは単純なアルゴリズムによって生成され、ディスク上のメモリ ブロックに不良が生じ、そこに格納されている値が破損していないかどうかを検出するために主に使用されます。 ファイル ハッシュは、ファイルの破損も検出するという点でチェックサムに似ています。 ただし、ほとんどのチェックサム アルゴリズムとは異なり、元の変更されていない値からファイル ハッシュを変更せずにファイルを変更することは非常に困難です。 したがって、ファイル ハッシュを使用すると、ウイルス、ハッカー、トロイの木馬プログラムなどのプログラムによって加えられた、ファイルに対する意図的かつ微妙な変更を検出できます。
証明書に含まれている場合、イメージ ダイジェストでは、オプションのヘッダー データ ディレクトリのチェックサムや証明書テーブル エントリなど、PE イメージ内の特定のフィールドを除外する必要があります。 これは、証明書を追加するとこれらのフィールドが変更され、別のハッシュ値が計算されるためです。
Win32 ImageGetDigestStream 関数は、関数をハッシュするターゲット PE ファイルからのデータ ストリームを提供します。 証明書が PE ファイルに追加または削除された場合に、このデータ ストリームは一貫性を保ちます。 ImageGetDigestStream に渡されるパラメーターに基づいて、PE イメージの他のデータをハッシュ計算から除外できます。 関数の参照ページへのリンクについては、「リファレンス」を参照してください。
遅延読み込みインポート テーブル (イメージのみ)
これらのテーブルは、アプリケーションがその DLL への最初の呼び出しが行われるまで DLL の読み込みを遅延させるための均一なメカニズムをサポートするために、イメージに追加されました。 テーブルのレイアウトは、セクション 6.4「.idata セクション」で説明されている従来のインポート テーブルのレイアウトと一致します。ここでは、いくつかの詳細について説明します。
遅延読み込みディレクトリ テーブル
遅延読み込みディレクトリ テーブルは、インポート ディレクトリ テーブルに対応します。 これは、オプションのヘッダー データ ディレクトリ リスト (オフセット 200) の遅延インポート記述子エントリを使用して取得できます。 テーブルの構成は次のとおりです。
| Offset | サイズ | フィールド | 説明 |
|---|---|---|---|
| 0 |
4 |
属性 |
ゼロを指定してください。 |
| 4 |
4 |
名前 |
読み込まれる DLL の名前の RVA。 この名前は、イメージの読み取り専用データ セクションにあります。 |
| 8 |
4 |
Module Handle |
遅延読み込みされる DLL のモジュール ハンドル (イメージのデータ セクション内) の RVA。 遅延読み込みを管理するために提供されるルーチンによってストレージに使用されます。 |
| 12 |
4 |
Delay Import Address Table |
遅延読み込みインポート アドレス テーブルの RVA。 詳細については、「遅延インポート アドレス テーブル」 (IAT) を参照してください。 |
| 16 |
4 |
Delay Import Name Table |
読み込む必要があるインポートの名前を含む遅延読み込み名前テーブルの RVA。 これは、インポート名前テーブルのレイアウトと一致します。 詳細については、「ヒント/名前テーブル」を参照してください。 |
| 20 |
4 |
Bound Delay Import Table |
バインド遅延読み込みアドレス テーブルの RVA (存在する場合)。 |
| 24 |
4 |
Unload Delay Import Table |
アンロード遅延読み込みアドレス テーブルの RVA (存在する場合)。 これは、遅延インポート アドレス テーブルの正確なコピーです。 呼び出し元が DLL をアンロードする場合、後続の DLL への呼び出しでサンク メカニズムが引き続き正しく使用されるように、このテーブルを遅延インポート アドレス テーブルにコピーして戻す必要があります。 |
| 28 |
4 |
タイム スタンプ |
このイメージがバインドされている DLL のタイムスタンプ。 |
このデータ構造で参照されるテーブルは、従来のインポートでの対応するテーブルと同様に構成および整列されています。 詳細については、「.idata セクション」を参照してください。
属性
属性フラグはまだ定義されていません。 リンカーによって、イメージ内でこのフィールドは 0 に設定されます。 このフィールドは、新しいフィールドの存在を示してレコードを拡張するために使用できます。または、遅延またはアンロード ヘルパー関数の動作を示すために使用できます。
名前
遅延読み込みされる DLL の名前は、イメージの読み取り専用データ セクションにあります。 szName フィールドを介して参照されます。
モジュール ハンドル
遅延読み込みされる DLL のハンドルは、イメージのデータ セクションにあります。 phmod フィールドはハンドルを指します。 指定された遅延読み込みヘルパーは、この場所を使用して、読み込まれた DLL にハンドルを格納します。
遅延インポート アドレス テーブル
遅延インポート アドレス テーブル (IAT) は、pIAT フィールドを介して遅延インポート記述子によって参照されます。 遅延読み込みヘルパーは、サンクが呼び出しループに入らなくなるように、これらのポインターを実際のエントリ ポイントで更新します。 関数ポインターには、式 pINT->u1.Function を使用してアクセスします。
遅延インポート名前テーブル
遅延インポート名前テーブル (INT) には、読み込みが必要になる可能性があるインポートの名前が含まれています。 これらの名前は、IAT 内の関数ポインターと同じ方法で順序付けされます。 標準の INT と同じ構造で構成され、式 pINT->u1.AddressOfData->Name[0] を使用してアクセスされます。
遅延バインド インポート アドレス テーブルとタイム スタンプ
遅延バインド インポート アドレス テーブル (BIAT) は、IMAGE_THUNK_DATA 項目のオプションのテーブルです。プロセス後のバインド フェーズによって、遅延読み込みディレクトリ テーブルのタイムスタンプ フィールドと共に使用されます。
遅延アンロード インポート アドレス テーブル
遅延アンロード インポート アドレス テーブル (UIAT) は、明示的なアンロード要求を処理するためにアンロード コードによって使用される IMAGE_THUNK_DATA 項目のオプションのテーブルです。 遅延読み込みサンクに対するコードを参照した元の IAT の正確なコピーである、読み取り専用セクション内の初期化されたデータで構成されます。 アンロード要求があると、ライブラリを解放し、*phmod をクリアし、IAT を UIAT で上書きして、すべてを読み込み前の状態に復元できます。
特殊セクション
- .debug セクション
- .drectve セクション (オブジェクトのみ)
- .edata セクション (イメージのみ)
- .idata セクション
- .pdata セクション
- .reloc セクション (イメージのみ)
- .tls セクション
- 読み込み構成構造体 (イメージのみ)
- .rsrc セクション
- .cormeta セクション (オブジェクトのみ)
- .sxdata セクション
典型的な COFF セクションには、リンカーと Microsoft Win32 ローダーによってセクションの内容に関する特別な知識なしに処理できるコードまたはデータが含まれています。 その内容は、リンクまたは実行されているアプリケーションにのみ関連します。
ただし、一部の COFF セクションは、オブジェクト ファイルまたはイメージ ファイル内にある場合は特別な意味を持ちます。 ツールとローダーがこれらのセクションを認識するのは、セクション ヘッダーに特別なフラグが設定されている、イメージのオプションのヘッダー内の特別な場所がそれらを指している、またはセクション名自体がセクションの特殊な機能を示しているためです。 (セクション名自体がセクションの特殊な機能を示していない場合でも、セクション名は規則によって記述されるため、この仕様の作成者はすべてのケースでセクション名を参照できます)。
予約済みセクションとその属性については、下の表で説明します。その後に、実行可能ファイルに保持されるセクションの種類と、拡張機能のメタデータを含むセクションの種類について詳しく説明します。
| セクション名 | Content | 特性 |
|---|---|---|
| .bss |
未初期化データ (自由形式) |
IMAGE_SCN_CNT_UNINITIALIZED_DATA | IMAGE_SCN_MEM_READ | IMAGE_SCN_MEM_WRITE |
| .cormeta |
オブジェクト ファイルにマネージド コードが含まれていることを示す CLR メタデータ |
IMAGE_SCN_LNK_INFO |
| .data |
初期化データ (自由形式) |
IMAGE_SCN_CNT_INITIALIZED_DATA | IMAGE_SCN_MEM_READ | IMAGE_SCN_MEM_WRITE |
| .debug$F |
生成された FPO デバッグ情報 (オブジェクトのみ、x86 アーキテクチャのみ、現在は廃止) |
IMAGE_SCN_CNT_INITIALIZED_DATA | IMAGE_SCN_MEM_READ | IMAGE_SCN_MEM_DISCARDABLE |
| .debug$P |
プリコンパイル済みのデバッグの種類 (オブジェクトのみ) |
IMAGE_SCN_CNT_INITIALIZED_DATA | IMAGE_SCN_MEM_READ | IMAGE_SCN_MEM_DISCARDABLE |
| .debug$S |
デバッグ シンボル (オブジェクトのみ) |
IMAGE_SCN_CNT_INITIALIZED_DATA | IMAGE_SCN_MEM_READ | IMAGE_SCN_MEM_DISCARDABLE |
| .debug$T |
デバッグの種類 (オブジェクトのみ) |
IMAGE_SCN_CNT_INITIALIZED_DATA | IMAGE_SCN_MEM_READ | IMAGE_SCN_MEM_DISCARDABLE |
| .drective |
リンカー オプション |
IMAGE_SCN_LNK_INFO |
| .edata |
エクスポート テーブル |
IMAGE_SCN_CNT_INITIALIZED_DATA | IMAGE_SCN_MEM_READ |
| .idata |
インポート テーブル |
IMAGE_SCN_CNT_INITIALIZED_DATA | IMAGE_SCN_MEM_READ | IMAGE_SCN_MEM_WRITE |
| .idlsym |
IDL 属性をサポートするために、登録済みの SEH (イメージのみ) が含まれます。 詳細については、このトピックの最後にある「リファレンス」の IDL 属性に関するページを参照してください。 |
IMAGE_SCN_LNK_INFO |
| .pdata |
例外情報 |
IMAGE_SCN_CNT_INITIALIZED_DATA | IMAGE_SCN_MEM_READ |
| .rdata |
読み取り専用の初期化データ |
IMAGE_SCN_CNT_INITIALIZED_DATA | IMAGE_SCN_MEM_READ |
| .reloc |
イメージの再配置 |
IMAGE_SCN_CNT_INITIALIZED_DATA | IMAGE_SCN_MEM_READ | IMAGE_SCN_MEM_DISCARDABLE |
| .rsrc |
リソース ディレクトリ |
IMAGE_SCN_CNT_INITIALIZED_DATA | IMAGE_SCN_MEM_READ |
| .sbss |
GP 相対の未初期化データ (自由形式) |
IMAGE_SCN_CNT_UNINITIALIZED_DATA | IMAGE_SCN_MEM_READ | IMAGE_SCN_MEM_WRITE | IMAGE _SCN_GPREL
IMAGE_SCN_GPREL フラグは、IA64 アーキテクチャにのみ設定する必要があります。このフラグは、他のアーキテクチャでは無効です。 IMAGE_SCN_GPREL フラグは、オブジェクト ファイル専用です。このセクションの種類がイメージ ファイルにある場合は、IMAGE_SCN_GPREL フラグを設定しないでください。 |
| .sdata |
GP 相対の初期化データ (自由形式) |
IMAGE_SCN_CNT_INITIALIZED_DATA | IMAGE_SCN_MEM_READ | IMAGE_SCN_MEM_WRITE | IMAGE _SCN_GPREL
IMAGE_SCN_GPREL フラグは、IA64 アーキテクチャにのみ設定する必要があります。このフラグは、他のアーキテクチャでは無効です。 IMAGE_SCN_GPREL フラグは、オブジェクト ファイル専用です。このセクションの種類がイメージ ファイルにある場合は、IMAGE_SCN_GPREL フラグを設定しないでください。 |
| .srdata |
GP 相対の読み取り専用データ (自由形式) |
IMAGE_SCN_CNT_INITIALIZED_DATA | IMAGE_SCN_MEM_READ | IMAGE _SCN_GPREL
IMAGE_SCN_GPREL フラグは、IA64 アーキテクチャにのみ設定する必要があります。このフラグは、他のアーキテクチャでは無効です。 IMAGE_SCN_GPREL フラグは、オブジェクト ファイル専用です。このセクションの種類がイメージ ファイルにある場合は、IMAGE_SCN_GPREL フラグを設定しないでください。 |
| .sxdata |
登録済みの例外ハンドラー データ (自由形式、x86/オブジェクトのみ) |
IMAGE_SCN_LNK_INFO
オブジェクト ファイル内のコードによって参照される各例外ハンドラーのシンボル インデックスが含まれます。 シンボルは、UNDEF シンボル、またはそのモジュールで定義されているシンボルの場合があります。 |
| .text |
実行可能コード (自由形式) |
IMAGE_SCN_CNT_CODE | IMAGE_SCN_MEM_EXECUTE | IIMAGE_SCN_MEM_READ |
| .tls |
スレッド ローカル ストレージ (オブジェクトのみ) |
IMAGE_SCN_CNT_INITIALIZED_DATA | IMAGE_SCN_MEM_READ | IMAGE_SCN_MEM_WRITE |
| .tls$ |
スレッド ローカル ストレージ (オブジェクトのみ) |
IMAGE_SCN_CNT_INITIALIZED_DATA | IMAGE_SCN_MEM_READ | IMAGE_SCN_MEM_WRITE |
| .vsdata |
GP 相対の初期化データ (自由形式。ARM、SH4、Thumb アーキテクチャのみ) |
IMAGE_SCN_CNT_INITIALIZED_DATA | IMAGE_SCN_MEM_READ | IMAGE_SCN_MEM_WRITE |
| .xdata |
例外情報 (自由形式) |
IMAGE_SCN_CNT_INITIALIZED_DATA | IMAGE_SCN_MEM_READ |
ここにリストされているセクションの一部には "オブジェクトのみ" または "イメージのみ" と書かれており、その特殊な意味がオブジェクト ファイルまたはイメージ ファイルにのみ関連することが示されています。 "イメージのみ" と書かれたセクションが、イメージ ファイルに入るための手段としてオブジェクト ファイル内に存在する場合がありますが、そのセクションはリンカーにとって特殊な意味を持たず、イメージ ファイル ローダーに対してのみ意味を持ちます。
.debug セクション
.debug セクションは、オブジェクト ファイルではコンパイラによって生成されたデバッグ情報を含めるために使用され、イメージ ファイルでは生成されるすべてのデバッグ情報を含めるために使用されます。 このセクションでは、オブジェクト ファイルとイメージ ファイルでのデバッグ情報のパッケージ化について説明します。
次のセクションでは、イメージ内の任意の場所に配置できるデバッグ ディレクトリの形式について説明します。 以降のセクションでは、デバッグ情報を含むオブジェクト ファイルの "グループ" について説明します。
リンカーの既定では、デバッグ情報がイメージのアドレス空間にマップされません。 .debug セクションは、デバッグ情報がアドレス空間にマップされている場合にのみ存在します。
デバッグ ディレクトリ (イメージのみ)
イメージ ファイルには、存在するデバッグ情報の形式とその場所を示すオプションのデバッグ ディレクトリが含まれています。 このディレクトリはデバッグ ディレクトリ エントリの配列で構成されており、その場所とサイズはイメージのオプションのヘッダー内で示されています。
デバッグ ディレクトリは、破棄可能な .debug セクション (ある場合) に存在する場合も、イメージ ファイル内の他のセクションに含まれている場合も、セクション内にまったく含まれない場合もあります。
各デバッグ ディレクトリ エントリは、デバッグ情報のブロックの場所とサイズを識別します。 デバッグ情報がセクション ヘッダーでカバーされていない (つまり、イメージ ファイル内に存在し、ランタイム アドレス空間にマップされていない) 場合、指定された RVA は 0 になることがあります。 マップされている場合、RVA はそのアドレスです。
デバッグ ディレクトリ エントリの形式は次のとおりです。
| Offset | サイズ | フィールド | 説明 |
|---|---|---|---|
| 0 |
4 |
特性 |
予約済み。0 である必要があります。 |
| 4 |
4 |
TimeDateStamp |
デバッグ データが作成された日時。 |
| 8 |
2 |
MajorVersion |
デバッグ データ形式のメジャー バージョン番号。 |
| 10 |
2 |
MinorVersion |
デバッグ データ形式のマイナー バージョン番号。 |
| 12 |
4 |
種類 |
デバッグ情報の形式。 このフィールドにより、複数のデバッガーをサポートできます。 詳細については、「デバッグの種類」を参照してください。 |
| 16 |
4 |
SizeOfData |
デバッグ データのサイズ (デバッグ ディレクトリ自体は含まれません)。 |
| 20 |
4 |
AddressOfRawData |
イメージ ベースに相対的な、読み込み時のデバッグ データのアドレス。 |
| 24 |
4 |
PointerToRawData |
デバッグ データへのファイル ポインター。 |
デバッグの種類
デバッグ ディレクトリ エントリの Type フィールドには、次の値が定義されています。
| 定数 | 値 | 説明 |
|---|---|---|
| IMAGE_DEBUG_TYPE_UNKNOWN |
0 |
すべてのツールで無視される不明な値。 |
| IMAGE_DEBUG_TYPE_COFF |
1 |
COFF デバッグ情報 (行番号、シンボル テーブル、および文字列テーブル)。 この種のデバッグ情報はまた、ファイル ヘッダー内のフィールドによって指し示されます。 |
| IMAGE_DEBUG_TYPE_CODEVIEW |
2 |
Visual C++ デバッグ情報。 |
| IMAGE_DEBUG_TYPE_FPO |
3 |
フレーム ポインター省略 (FPO) 情報。 この情報は、EBP レジスタをフレーム ポインター以外の目的で使用する非標準スタック フレームの解釈方法をデバッガーに伝えます。 |
| IMAGE_DEBUG_TYPE_MISC |
4 |
DBG ファイルの場所。 |
| IMAGE_DEBUG_TYPE_EXCEPTION |
5 |
.pdata セクションのコピー。 |
| IMAGE_DEBUG_TYPE_FIXUP |
6 |
予約済み。 |
| IMAGE_DEBUG_TYPE_OMAP_TO_SRC |
7 |
イメージ内の RVA からソース イメージの RVA へのマッピング。 |
| IMAGE_DEBUG_TYPE_OMAP_FROM_SRC |
8 |
ソース イメージ内の RVA からイメージの RVA へのマッピング。 |
| IMAGE_DEBUG_TYPE_BORLAND |
9 |
Borland 用に予約されています。 |
| IMAGE_DEBUG_TYPE_RESERVED10 |
10 |
予約済み。 |
| IMAGE_DEBUG_TYPE_CLSID |
11 |
予約済み。 |
| IMAGE_DEBUG_TYPE_REPRO |
16 |
PE の決定性または再現性。 |
| 未定義。 |
17 |
デバッグ情報は、PointerToRawData によって指定された場所にある PE ファイルに埋め込まれます。 |
| 未定義。 |
19 |
PE/COFF ファイルのビルドに使用されるシンボル ファイルの内容の暗号化ハッシュを格納します。 |
| IMAGE_DEBUG_TYPE_EX_DLLCHARACTERISTICS | 20 | 拡張 DLL 特性ビット。 |
Type フィールドが IMAGE_DEBUG_TYPE_FPO に設定されている場合、デバッグ生データは、各メンバーが関数のスタック フレームを記述する配列です。 デバッグの種類が FPO であっても、イメージ ファイル内のすべての関数に FPO 情報が定義されている必要があるわけではありません。 FPO 情報を持たない関数は、通常のスタック フレームを持つものと見なされます。 FPO 情報の形式は次のとおりです。
#define FRAME_FPO 0
#define FRAME_TRAP 1
#define FRAME_TSS 2
typedef struct _FPO_DATA {
DWORD ulOffStart; // offset 1st byte of function code
DWORD cbProcSize; // # bytes in function
DWORD cdwLocals; // # bytes in locals/4
WORD cdwParams; // # bytes in params/4
WORD cbProlog : 8; // # bytes in prolog
WORD cbRegs : 3; // # regs saved
WORD fHasSEH : 1; // TRUE if SEH in func
WORD fUseBP : 1; // TRUE if EBP has been allocated
WORD reserved : 1; // reserved for future use
WORD cbFrame : 2; // frame type
} FPO_DATA;
IMAGE_DEBUG_TYPE_REPRO の種類のエントリがある場合、PE ファイルが決定性または再現性を実現する方法で構築されていることを示します。 入力が変更されない場合、出力 PE ファイルは、PE が生成されるタイミングや場所に関係なく、ビット単位で同一であることが保証されます。 PE ファイル内のさまざまな日付/時刻スタンプ フィールドには、PE ファイルの内容を入力として使用する計算されたハッシュ値の一部またはすべてのビットが入力されるため、PE ファイルまたは PE 内の特定の関連データが生成された実際の日付や時刻を表さなくなります。 このデバッグ エントリの生データは空であるか、ハッシュ値の長さを表す 4 バイト値に続いて、計算されたハッシュ値を含む場合があります。
Type フィールドが IMAGE_DEBUG_TYPE_EX_DLLCHARACTERISTICS に設定されている場合、デバッグ生データには、イメージのオプションのヘッダーで設定できるビットに加えて、拡張 DLL 特性ビットが含まれます。 「DLL の特性」の「オプションのヘッダーの Windows 固有フィールド (イメージのみ)」セクションを参照してください。
拡張 DLL 特性
拡張 DLL 特性ビットには、次の値が定義されています。
| 定数 | 値 | 説明 |
|---|---|---|
| IMAGE_DLLCHARACTERISTICS_EX_CET_COMPAT | 0x0001 | イメージは、制御フロー強制テクノロジ (CET) シャドウ スタック互換です。 |
| IMAGE_DLLCHARACTERISTICS_EX_FORWARD_CFI_COMPAT | 0x0040 | すべてのイメージ コード セクション内のすべてのブランチ ターゲットには、x86 CET-Indirect Branch Tracking (IBT) や ARM Branch Target Identification (BTI) 命令などの順方向エッジ制御フロー整合性ガード命令で注釈が付けられます。 このビットは Windows では使用されません。 |
.debug$F (オブジェクトのみ)
このセクションのデータは、Visual C++ バージョン 7.0 以降では、.debug$S サブセクションに出力されるより広範なデータ セットに置き換えられます。
オブジェクト ファイルには、その内容が 1 つ以上の FPO_DATA レコード (フレーム ポインター省略情報) である .debug$F セクションが含まれている場合があります。 「デバッグの種類」の「IMAGE_DEBUG_TYPE_FPO」を参照してください。
リンカーは、これらの .debug$F レコードを認識します。 デバッグ情報が生成されている場合、リンカーはプロシージャ RVA で FPO_DATA レコードを並べ替え、それらのデバッグ ディレクトリ エントリを生成します。
コンパイラは、標準フレーム形式のプロシージャの FPO レコードを生成しません。
.debug$S (オブジェクトのみ)
このセクションには、Visual C++ デバッグ情報 (シンボル情報) が含まれています。
.debug$P (オブジェクトのみ)
このセクションには、Visual C++ デバッグ情報 (プリコンパイル情報) が含まれています。 これらは、このオブジェクトで生成されたプリコンパイル済みヘッダーを使用してコンパイルされたすべてのオブジェクト間で共有される種類です。
.debug$T (オブジェクトのみ)
このセクションには、Visual C++ デバッグ情報 (種類の情報) が含まれています。
Microsoft デバッグ情報のリンカーによるサポート
デバッグ情報をサポートするために、リンカーは以下を実行します。
.debug$F、debug$S、.debug$P、.debug$T セクションから関連するすべてのデバッグ データを収集します。
そのデータを、リンカーが生成したデバッグ情報と共に PDB ファイルに処理し、それを参照するデバッグ ディレクトリ エントリを作成します。
.drectve セクション (オブジェクトのみ)
セクション ヘッダーに IMAGE_SCN_LNK_INFO フラグが設定され、セクション名が .drectve の場合、そのセクションはディレクティブ セクションです。 リンカーは、情報を処理した後に .drectve セクションを削除するため、リンクされているイメージ ファイルにこのセクションはありません。
.drectve セクションは、ANSI または UTF-8 としてエンコードできるテキストの文字列で構成されます。 UTF-8 のバイト順マーカー (BOM: 0xEF、0xBB、0xBF で構成される 3 バイトのプレフィックス) が存在しない場合、ディレクティブ文字列は ANSI として解釈されます。 ディレクティブ文字列は、スペースで区切られた一連のリンカー オプションです。 各オプションには、ハイフン、オプション名、適切な属性が含まれます。 オプションにスペースが含まれている場合は、オプションを引用符で囲む必要があります。 .drectve セクションには再配置や行番号を含めることはできません。
.edata セクション (イメージのみ)
.edata という名前のエクスポート データ セクションには、他の画像が動的リンクを使用してアクセスできるシンボルに関する情報が含まれています。 通常、DLL にはエクスポートされたシンボルがありますが、DLL ではシンボルをインポートすることもできます。
エクスポート セクションの一般的な構造の概要は下に示すとおりです。 説明されているテーブルは、通常、ファイル内で示されている順序で連続しています (ただし、これは必須ではありません)。 シンボルを序数としてエクスポートする必要があるのは、エクスポート ディレクトリ テーブルとエクスポート アドレス テーブルのみです。 (序数は、エクスポート アドレス テーブル インデックスによって直接アクセスされるエクスポートです)。名前ポインター テーブル、序数テーブル、およびエクスポート名テーブルはすべて、エクスポート名の使用をサポートするために存在します。
| テーブル名 | 説明 |
|---|---|
| エクスポート ディレクトリ テーブル |
1 行だけからなるテーブル (デバッグ ディレクトリとは異なります)。 このテーブルは他のエクスポート テーブルの場所とサイズを示します。 |
| エクスポート アドレス テーブル |
エクスポートされたシンボルの RVA の配列。 これらは、実行可能コードとデータ セクション内のエクスポートされた関数とデータの実際のアドレスです。 他のイメージ ファイルでは、このテーブルのインデックス (序数) を使用して、または必要に応じて、パブリック名が定義されている場合は序数に対応するパブリック名を使用して、シンボルをインポートできます。 |
| 名前ポインター テーブル |
パブリック エクスポート名へのポインターの配列。昇順で並べ替えられています。 |
| 序数テーブル |
名前ポインター テーブルのメンバーに対応する序数の配列。 位置によって対応します。したがって、名前ポインター テーブルと序数テーブルのメンバー数は同じである必要があります。 各序数は、エクスポート アドレス テーブルへのインデックスです。 |
| エクスポート名テーブル |
null で終わる一連の ASCII 文字列。 名前ポインター テーブルのメンバーがこの領域を指します。 これらの名前はパブリック名で、これらを通じてシンボルがインポートおよびエクスポートされます。イメージ ファイル内で使用されるプライベート名と必ずしも同じではありません。 |
別のイメージ ファイルが名前でシンボルをインポートすると、Win32 ローダーは名前ポインター テーブルで一致する文字列を検索します。 一致する文字列が見つかった場合、関連付けられている序数は、序数テーブル内の対応するメンバー (つまり、名前ポインター テーブル内の文字列ポインターと同じインデックスを持つ序数テーブルのメンバー) を検索することによって識別されます。 結果として得られる序数は、エクスポート アドレス テーブルへのインデックスであり、目的のシンボルの実際の場所を示します。 すべてのエクスポート シンボルには、序数によってアクセスできます。
別のイメージ ファイルに序数でシンボルをインポートすると、名前ポインター テーブルで一致する文字列を検索する必要はありません。 したがって、序数を直接使用する方が効率的です。 ただし、エクスポート名は覚えやすく、ユーザーはシンボルのテーブル インデックスを知る必要がありません。
エクスポート ディレクトリ テーブル
エクスポート シンボル情報はエクスポート ディレクトリ テーブルで始まり、エクスポート シンボル情報の残りの部分が記述されます。 エクスポート ディレクトリ テーブルには、このイメージ内のエントリ ポイントへのインポートを解決するために使用されるアドレス情報が含まれています。
| Offset | サイズ | フィールド | 説明 |
|---|---|---|---|
| 0 |
4 |
Export Flags |
予約済み。0 である必要があります。 |
| 4 |
4 |
Time/Date Stamp |
エクスポート データが作成された日時。 |
| 8 |
2 |
メジャー バージョン |
メジャー バージョン番号。 メジャーおよびマイナー バージョン番号はユーザーが設定できます。 |
| 10 |
2 |
マイナー バージョン |
マイナー バージョン番号。 |
| 12 |
4 |
Name RVA |
DLL の名前を含む ASCII 文字列のアドレス。 このアドレスはイメージ ベースに対して相対的です。 |
| 16 |
4 |
Ordinal Base |
このイメージ内のエクスポートの開始序数。 このフィールドは、エクスポート アドレス テーブルの開始序数を指定します。 通常は 1 に設定されます。 |
| 20 |
4 |
Address Table Entries |
エクスポート アドレス テーブル内のエントリの数。 |
| 24 |
4 |
名前ポインターの数 |
名前ポインター テーブル内のエントリの数。 これは、序数テーブル内のエントリの数でもあります。 |
| 28 |
4 |
Export Address Table RVA |
イメージ ベースに相対的なエクスポート アドレス テーブルのアドレス。 |
| 32 |
4 |
Name Pointer RVA |
イメージ ベースに相対的なエクスポート名ポインター テーブルのアドレス。 テーブルのサイズは、名前ポインターの数フィールドで指定します。 |
| 36 |
4 |
Ordinal Table RVA |
イメージ ベースに相対的な序数テーブルのアドレス。 |
エクスポート アドレス テーブル
エクスポート アドレス テーブルには、エクスポートされたエントリ ポイントのアドレスと、エクスポートされたデータと絶対値が含まれます。 序数は、エクスポート アドレス テーブルへのインデックスとして使用されます。
エクスポート アドレス テーブルの各エントリは、次の表の 2 つの形式のいずれかを使用するフィールドです。 指定されたアドレスがエクスポート セクション内にない場合 (オプションのヘッダーに示されているアドレスと長さによって定義されます)、このフィールドはエクスポートの RVA です。これはコードまたはデータの実際のアドレスです。 それ以外の場合、このフィールドはフォワーダーの RVA であり、別の DLL のシンボルに名前を指定します。
| Offset | サイズ | フィールド | 説明 |
|---|---|---|---|
| 0 |
4 |
Export RVA |
メモリに読み込まれるときのエクスポートされたシンボルのアドレス。イメージ ベースに対して相対的です。 たとえば、エクスポートされた関数のアドレスなどです。 |
| 0 |
4 |
Forwarder RVA |
エクスポート セクションの null で終わる ASCII 文字列へのポインター。 この文字列は、エクスポート テーブルのデータ ディレクトリ エントリによって指定される範囲内である必要があります。 「オプションのヘッダーのデータ ディレクトリ (イメージのみ)」を参照してください。 この文字列は、DLL 名とエクスポートの名前 ("MYDLL.expfunc" など) または DLL 名とエクスポートの序数 ("MYDLL.#27" など) を指定します。 |
フォワーダーの RVA は他のイメージから定義をエクスポートし、現在のイメージによってエクスポートされたように見せます。 したがって、シンボルは同時にインポートおよびエクスポートされます。
たとえば、Windows XP のKernel32.dll では、"HeapAlloc" という名前のエクスポートが文字列 "NTDLL.RtlAllocateHeap" に転送されます。これにより、アプリケーションは、Windows XP 固有のモジュール Ntdll.dll にインポート参照を含めずに、このモジュールを使用できます。 アプリケーションのインポート テーブルは、Kernel32.dll のみを参照します。 したがって、アプリケーションは Windows XP に固有ではなく、すべての Win32 システムで実行できます。
エクスポート名ポインター テーブル
エクスポート名ポインター テーブルは、エクスポート名テーブルへのアドレス (RVA) の配列です。 ポインターはそれぞれ 32 ビットであり、イメージ ベースに相対的です。 ポインターは辞書順に並べられており、バイナリ検索が可能です。
エクスポート名は、それに対するポインターがエクスポート名ポインター テーブルに含まれている場合にのみ定義されます。
エクスポート序数テーブル
エクスポート序数テーブルは、エクスポート アドレス テーブルへの 16 ビットのバイアスのかかっていないインデックスの配列です。 序数は、エクスポート ディレクトリ テーブルの序数ベース フィールドによってバイアスがかけられています。 つまり、エクスポート アドレス テーブルへの真のインデックスを取得するには、序数から序数ベースを引く必要があります。
エクスポート名ポインター テーブルとエクスポート序数テーブルは、自然なフィールドの配置を可能にするために分離された 2 つの並列配列を形成します。 実際には、これらの 2 つのテーブルは 1 つのテーブルとして動作し、エクスポート名ポインター列がパブリック (エクスポートされた) 名を指し、エクスポート序数列がそのパブリック名に対応する序数を指定します。 エクスポート名ポインター テーブルのメンバーとエクスポート序数テーブルのメンバーは、それぞれの配列内で同じ位置 (インデックス) を持つことによって関連付けられます。
したがって、エクスポート名ポインター テーブルが検索され、一致する文字列が位置 i で見つかった場合、シンボルの RVA とバイアスがかかった序数を検索するためのアルゴリズムは次のようになります。
i = Search_ExportNamePointerTable (name);
ordinal = ExportOrdinalTable [i];
rva = ExportAddressTable [ordinal];
biased_ordinal = ordinal + OrdinalBase;
(バイアスのかけられた) 序数でシンボルを検索する場合、シンボルの RVA と名前を検索するためのアルゴリズムは次のようになります。
ordinal = biased_ordinal - OrdinalBase;
i = Search_ExportOrdinalTable (ordinal);
rva = ExportAddressTable [ordinal];
name = ExportNameTable [i];
エクスポート名テーブル
エクスポート名テーブルには、エクスポート名ポインター テーブルによって指し示された実際の文字列データが含まれています。 このテーブル内の文字列は、他のイメージがシンボルのインポートに使用できるパブリック名です。 これらのパブリック エクスポート名は、シンボルがそれ自体のイメージ ファイルとソース コード内に持つプライベート シンボル名と必ずしも同じとは限りませんが、同じである場合もあります。
エクスポートされたすべてのシンボルには、エクスポート アドレス テーブルへの単なるインデックスである序数値があります。 ただし、エクスポート名の使用はオプションです。 エクスポートされたシンボルの一部またはすべてにエクスポート名がある場合も、いずれにもエクスポート名がない場合もあります。 エクスポート名を持つエクスポートされたシンボルの場合、エクスポート名ポインター テーブルとエクスポート序数テーブル内の対応するエントリが連携して、各名前を序数に関連付けます。
エクスポート名テーブルの構造は、可変長の null で終わる一連の ASCII 文字列です。
.idata セクション
シンボルをインポートするすべてのイメージ ファイル (ほぼすべての実行可能ファイル (EXE) ファイルを含む) には、.idata セクションがあります。 インポート情報の典型的なファイル レイアウトは次のとおりです。
Directory テーブル
Null ディレクトリ エントリ
DLL1 インポート ルックアップ テーブル
[Null]
DLL2 インポート ルックアップ テーブル
[Null]
DLL3 インポート ルックアップ テーブル
[Null]
ヒント/名前 テーブル
インポート ディレクトリ テーブル
インポート情報は、インポート ディレクトリ テーブルから始まります。このテーブルには、インポート情報の残りの部分が記述されます。 インポート ディレクトリ テーブルには、DLL イメージ内のエントリ ポイントへのフィックスアップ参照を解決するために使用されるアドレス情報が含まれています。 インポート ディレクトリ テーブルは、インポート ディレクトリ エントリの配列で構成されます。エントリは、イメージが参照する DLL ごとに 1 つあります。 最後のディレクトリ エントリは空です (null 値で埋められます)。これは、ディレクトリ テーブルの終わりを示します。
各インポート ディレクトリ エントリの形式は次のとおりです。
| Offset | サイズ | フィールド | 説明 |
|---|---|---|---|
| 0 |
4 |
Import Lookup Table RVA (Characteristics) |
インポート ルックアップ テーブルの RVA。 このテーブルには、インポートごとに名前または序数が含まれます。 ("Characteristics" という名前が Winnt.h で使用されていますが、このフィールドの説明としては合わなくなっています)。 |
| 4 |
4 |
Time/Date Stamp |
イメージがバインドされるまで 0 に設定されるスタンプ。 イメージがバインドされると、このフィールドは DLL の時刻/日付スタンプに設定されます。 |
| 8 |
4 |
Forwarder Chain |
最初のフォワーダー参照のインデックス。 |
| 12 |
4 |
Name RVA |
DLL の名前を含む ASCII 文字列のアドレス。 このアドレスはイメージ ベースに対して相対的です。 |
| 16 |
4 |
Import Address Table RVA (Thunk Table) |
インポート アドレス テーブルの RVA。 このテーブルの内容は、イメージがバインドされるまで、インポート ルックアップ テーブルの内容と同じです。 |
インポート ルックアップ テーブル
インポート ルックアップ テーブルは、PE32 の場合は 32 ビット数の配列、または PE32+ の場合は 64 ビット数の配列です。 各エントリでは、次の表に示すビット フィールド形式が使用されます。 この形式では、ビット 31 が PE32 の最上位ビットであり、ビット 63 が PE32+ の最上位ビットです。 これらのエントリのコレクションによって、指定の DLL からのすべてのインポートが記述されます。 最後のエントリは、テーブルの終わりを示す 0 (NULL) に設定されます。
| ビット | サイズ | ビット フィールド | Description |
|---|---|---|---|
| 31/63 |
1 |
Ordinal/Name Flag |
このビットが設定されている場合は、序数でインポートされます。 そうでない場合は、名前でインポートされます。 ビットは、PE32 の場合は 0x80000000、PE32+ の場合は 0x8000000000000000 でマスクされます。 |
| 15-0 |
16 |
Ordinal Number |
16 ビットの序数。 このフィールドは、Ordinal/Name Flag ビット フィールドが 1 (序数でインポート) の場合にのみ使用されます。 ビット 30-15 または 62-15 は 0 である必要があります。 |
| 30-0 |
31 |
Hint/Name Table RVA |
ヒント/名前テーブル エントリの 31 ビット RVA。 このフィールドは、Ordinal/Name Flag ビット フィールドが 0 (名前でインポート) の場合にのみ使用されます。 PE32+ の場合、ビット 62-31 は 0 である必要があります。 |
ヒント/名前テーブル
インポート セクション全体で 1 つのヒント/名前テーブルがあれば十分です。 ヒント/名前テーブルの各エントリの形式は次のとおりです。
| Offset | サイズ | フィールド | 説明 |
|---|---|---|---|
| 0 |
2 |
Hint |
エクスポート名ポインター テーブルへのインデックス。 まず、この値で一致するかどうかが試されます。 失敗した場合は、DLL のエクスポート名ポインター テーブルに対してバイナリ検索が実行されます。 |
| 2 |
変数 |
名前 |
インポートする名前を含む ASCII 文字列。 これは、DLL 内のパブリック名と一致する必要がある文字列です。 この文字列では大文字と小文字が区別され、null バイトで終了します。 |
| * |
0 または 1 |
Pad |
必要に応じて、末尾の null バイトの後に続く 0 の埋め込みバイト。次のエントリを偶数境界に配置します。 |
インポート アドレス テーブル
インポート アドレス テーブルの構造と内容は、ファイルがバインドされるまでは、インポート ルックアップ テーブルと同じです。 バインドされている間、インポート アドレス テーブル内のエントリは、インポートされているシンボルの 32 ビット (PE32 の場合) または 64 ビット (PE32+ の場合) アドレスで上書きされます。 これらのアドレスはシンボルの実際のメモリ アドレスですが、技術的には "仮想アドレス" と呼ばれています。バインドの処理は通常、ローダーによって行われます。
.pdata セクション
.pdata セクションには、例外処理に使用される関数テーブル エントリの配列が含まれています。 これは、イメージ データ ディレクトリ内の例外テーブル エントリによって指し示されます。 エントリは、最終的なイメージに出力される前に、関数アドレス (各構造体の最初のフィールド) に従って並べ替えられる必要があります。 ターゲット プラットフォームは、下で説明する 3 つの関数テーブル エントリ形式のバリエーションのうちどれを使用するかを決定します。
32 ビット MIPS イメージの場合、関数テーブル エントリの形式は次のとおりです。
| Offset | サイズ | フィールド | 説明 |
|---|---|---|---|
| 0 |
4 |
Begin Address |
対応する関数の VA。 |
| 4 |
4 |
終了アドレス |
関数の末尾の VA。 |
| 8 |
4 |
例外ハンドラー |
実行される例外ハンドラーへのポインター。 |
| 12 |
4 |
Handler Data |
ハンドラーに渡される追加情報へのポインター。 |
| 16 |
4 |
Prolog End Address |
関数のプロローグの末尾の VA。 |
Windows CE プラットフォームの ARM、PowerPC、SH3、SH4 の場合、関数テーブル エントリの形式は次のとおりです。
| Offset | サイズ | フィールド | 説明 |
|---|---|---|---|
| 0 |
4 |
Begin Address |
対応する関数の VA。 |
| 4 |
8 ビット |
Prolog Length |
関数のプロローグ内の命令の数。 |
| 4 |
22 ビット |
Function Length |
関数内の命令の数。 |
| 4 |
1 ビット |
32-bit Flag |
設定されている場合、関数は 32 ビット命令で構成されます。 クリアされている場合、関数は 16 ビット命令で構成されます。 |
| 4 |
1 ビット |
Exception Flag |
設定されている場合、関数の例外ハンドラーが存在します。 それ以外の場合、例外ハンドラーは存在しません。 |
x64 および Itanium プラットフォームの場合、関数テーブル エントリの形式は次のとおりです。
| Offset | サイズ | フィールド | 説明 |
|---|---|---|---|
| 0 |
4 |
Begin Address |
対応する関数の RVA。 |
| 4 |
4 |
終了アドレス |
関数の末尾の RVA。 |
| 8 |
4 |
Unwind Information |
アンワインド情報の RVA。 |
.reloc セクション (イメージのみ)
ベース再配置テーブルには、イメージ内のすべてのベース再配置のエントリが含まれています。 オプションのヘッダー データ ディレクトリの Base Relocation Table フィールドには、ベース再配置テーブルのバイト数が指定されます。 詳細については、「オプションのヘッダーのデータ ディレクトリ (イメージのみ)」を参照してください。 ベース再配置テーブルはブロックに分割されます。 各ブロックは、4K ページのベース再配置を表します。 各ブロックは、32 ビット境界で開始する必要があります。
読み込みイメージを PE ヘッダーで指定されたイメージ ベースに読み込めない場合を除いて、リンカーによって解決されるベース再配置の処理にローダーは必要ありません。
ベース再配置ブロック
各ベース再配置ブロックは、次の構造体で始まります。
| Offset | サイズ | フィールド | 説明 |
|---|---|---|---|
| 0 |
4 |
Page RVA |
イメージベースにページの RVA を加えたものが各オフセットに加算され、ベース再配置を適用する必要がある VA が作成されます。 |
| 4 |
4 |
ブロック サイズ |
Page RVA と Block Size フィールド、および後続の Type または Offset フィールドを含む、ベース再配置ブロックの合計バイト数。 |
Block Size フィールドの後に、任意の数の Type または Offset フィールドのエントリが続きます。 各エントリはワード (2 バイト) であり、次の構造を持ちます。
| Offset | サイズ | フィールド | 説明 |
|---|---|---|---|
| 0 |
4 ビット |
Type |
ワードの上位 4 ビットに格納されます。適用するベース再配置の種類を示す値です。 詳細については、「ベース再配置の種類」を参照してください。 |
| 0 |
12 ビット |
Offset |
ワードの残りの 12 ビットに格納されます。ブロックの Page RVA フィールドで指定された開始アドレスからのオフセットです。 このオフセットは、ベース再配置を適用する場所を指定します。 |
ベース再配置を適用するために、指定ベース アドレスと、イメージが実際に読み込まれるベースとの差異が計算されます。 イメージが指定ベースで読み込まれる場合、差異は 0 であるため、ベース再配置を適用する必要はありません。
ベース再配置の種類
| 定数 | 値 | 説明 |
|---|---|---|
| IMAGE_REL_BASED_ABSOLUTE |
0 |
ベース再配置はスキップされます。 この種類は、ブロックを埋めるために使用できます。 |
| IMAGE_REL_BASED_HIGH |
1 |
このベース再配置では、差異の上位 16 ビットがオフセットの 16 ビット フィールドに追加されます。 この 16 ビット フィールドは、32 ビット ワードの上位の値を表します。 |
| IMAGE_REL_BASED_LOW |
2 |
このベース再配置では、差異の下位 16 ビットがオフセットの 16 ビット フィールドに追加されます。 この 16 ビット フィールドは、32 ビット ワードの下位の半分を表します。 |
| IMAGE_REL_BASED_HIGHLOW |
3 |
このベース再配置では、差異の 32 ビットすべてがオフセットの 32 ビット フィールドに適用されます。 |
| IMAGE_REL_BASED_HIGHADJ |
4 |
このベース再配置では、差異の上位 16 ビットがオフセットの 16 ビット フィールドに追加されます。 この 16 ビット フィールドは、32 ビット ワードの上位の値を表します。 32 ビット値の下位 16 ビットは、このベース再配置の後に続く 16 ビット ワードに格納されます。 これは、このベース再配置が 2 つのスロットを占有することを意味します。 |
| IMAGE_REL_BASED_MIPS_JMPADDR |
5 |
この再配置の解釈は、マシンの種類によって異なります。 マシンの種類が MIPS の場合、ベース再配置は MIPS ジャンプ命令に適用されます。 |
| IMAGE_REL_BASED_ARM_MOV32 |
5 |
この再配置は、マシンの種類が ARM または Thumb の場合のみ有効です。 このベース再配置では、連続する MOVW/MOVT 命令ペア全体にシンボルの 32 ビット アドレスが適用されます。 |
| IMAGE_REL_BASED_RISCV_HIGH20 |
5 |
この再配置は、マシンの種類が RISC-V の場合のみ有効です。 このベース再配置は、32 ビット絶対アドレスの上位 20 ビットに適用されます。 |
| 6 |
予約済み。0 である必要があります。 |
|
| IMAGE_REL_BASED_THUMB_MOV32 |
7 |
この再配置は、マシンの種類が Thumb の場合のみ有効です。 このベース再配置では、連続する MOVW/MOVT 命令ペアにシンボルの 32 ビット アドレスが適用されます。 |
| IMAGE_REL_BASED_RISCV_LOW12I |
7 |
この再配置は、マシンの種類が RISC-V の場合のみ有効です。 このベース再配置は、RISC-V I 型命令形式で形成された 32 ビット絶対アドレスの下位 12 ビットに適用されます。 |
| IMAGE_REL_BASED_RISCV_LOW12S |
8 |
この再配置は、マシンの種類が RISC-V の場合のみ有効です。 このベース再配置は、RISC-V S 型命令形式で形成された 32 ビット絶対アドレスの下位 12 ビットに適用されます。 |
| IMAGE_REL_BASED_LOONGARCH32_MARK_LA |
8 |
この再配置は、マシンの種類が LoongArch 32 ビットの場合のみ有効です。 このベース再配置は、連続する 2 つの命令で形成された 32 ビットの絶対アドレスに適用されます。 |
| IMAGE_REL_BASED_LOONGARCH64_MARK_LA |
8 |
この再配置は、マシンの種類が LoongArch 64 ビットの場合のみ有効です。 このベース再配置は、連続する 4 つの命令で形成された 64 ビットの絶対アドレスに適用されます。 |
| IMAGE_REL_BASED_MIPS_JMPADDR16 |
9 |
この再配置は、マシンの種類が MIPS の場合のみ有効です。 このベース再配置は、MIPS16 ジャンプ命令に適用されます。 |
| IMAGE_REL_BASED_DIR64 |
10 |
このベース再配置では、オフセットの 64 ビット フィールドに差異が適用されます。 |
.tls セクション
.tls セクションは、静的スレッド ローカル ストレージ (TLS) に対する PE と COFF の直接サポートを提供します。 TLS は Windows がサポートする特別なストレージ クラスであり、データ オブジェクトが自動 (スタック) 変数ではなく、コードを実行する個々のスレッドに対してローカルとなります。 したがって、各スレッドでは、TLS を使用して宣言された変数に異なる値を保持できます。
API 呼び出しの TlsAlloc、TlsFree、TlsSetValue、TlsGetValue を使用して、任意の量の TLS データをサポートできます。 PE または COFF の実装は、API を使用するための代替アプローチであり、高水準言語のプログラマの観点からは、より単純であるという利点があります。 この実装により、プログラム内の通常の静的変数と同様の方法で、TLS データを定義および初期化できます。 たとえば、Visual C++ では、Windows API を使用せずに、静的 TLS 変数を次のように定義できます。
__declspec (thread) int tlsFlag = 1;
このプログラミング コンストラクトをサポートするために、PE と COFF の .tls セクションでは、初期化データ、スレッドごとの初期化と終了のコールバック ルーチン、TLS インデックスの情報を指定します。これらについては、以下で説明します。
注意
静的に宣言された TLS データ オブジェクトは、静的に読み込まれたイメージ ファイル内でのみ使用できます。 この事実により、DLL (または静的にリンクされているもの) が LoadLibrary API 関数によって動的に読み込まれることがないとわかっている場合を除き、DLL での静的 TLS データの使用は信頼性が低くなります。
実行可能コードは、次の手順を使用して静的 TLS データ オブジェクトにアクセスします。
リンク時に、リンカーは TLS ディレクトリの Address of Index フィールドを設定します。 このフィールドは、プログラムで TLS インデックスを受け取ると想定されている場所を指します。
Microsoft ランタイム ライブラリでは、TLS ディレクトリのメモリ イメージを定義し、"__tls_used" (Intel x86 プラットフォーム) または "_tls_used" (その他のプラットフォーム) という特別な名前を付けることで、このプロセスを容易にします。 リンカーはこのメモリ イメージを検索し、そこにあるデータを使用して TLS ディレクトリを作成します。 TLS をサポートし、Microsoft リンカーを使う他のコンパイラでも、この同じ手法を使用する必要があります。
スレッドが作成されると、ローダーはスレッド環境ブロック (TEB) のアドレスを FS レジスタに配置することで、スレッドの TLS 配列のアドレスを伝えます。 TLS 配列へのポインターは、TEB の先頭から 0x2C のオフセットにあります。 この動作は Intel x86 固有です。
ローダーは、Address of Index フィールドで示された場所に TLS インデックスの値を割り当てます。
実行可能コードは、この TLS インデックスと TLS 配列の場所も取得します。
このコードでは、TLS インデックスと TLS 配列の場所 (インデックスに 4 を乗算し、配列へのオフセットとして使用) を使用して、指定されたプログラムとモジュールの TLS データ領域のアドレスを取得します。 各スレッドには独自の TLS データ領域がありますが、これはプログラムに対して透過的であり、個々のスレッドにどのようにデータが割り当てられるかを知る必要はありません。
個々の TLS データ オブジェクトは、TLS データ領域への固定オフセットとしてアクセスされます。
TLS 配列は、システムが各スレッドに対して保持するアドレスの配列です。 この配列の各アドレスは、プログラム内の特定のモジュール (EXE または DLL) の TLS データの場所を示します。 TLS インデックスは、使用する配列のメンバーを示します。 インデックスは、モジュールを識別する数値です (そのシステムに対してのみ意味があります)。
TLS ディレクトリ
TLS ディレクトリの形式は次のとおりです。
| オフセット (PE32/PE32+) | サイズ (PE32/PE32+) | フィールド | 説明 |
|---|---|---|---|
| 0 |
4/8 |
Raw Data Start VA |
TLS テンプレートの開始アドレス。 テンプレートは、TLS データを初期化するために使用されるデータのブロックです。 システムは、スレッドが作成されるたびにこのデータをすべてコピーするため、破損しないようにする必要があります。 このアドレスは RVA ではないことに注意してください。これは、.reloc セクション内のベース再配置が存在する必要があるアドレスです。 |
| 4/8 |
4/8 |
Raw Data End VA |
0 の埋め込みを除く、TLS の最後のバイトのアドレス。 Raw Data Start VA フィールドと同様に、これは RVA ではなく VA です。 |
| 8/16 |
4/8 |
Address of Index |
ローダーが割り当てる TLS インデックスを受け取る場所。 この場所は通常のデータ セクション内にあります。そのため、プログラムにアクセスできるシンボリック名を指定できます。 |
| 12/24 |
4/8 |
Address of Callbacks |
TLS コールバック関数の配列へのポインター。 配列は null で終わるので、コールバック関数がサポートされていない場合、このフィールドは 0 が設定された 4 バイトを指します。 これらの関数のプロトタイプについては、「TLS コールバック関数」を参照してください。 |
| 16/32 |
4 |
Size of Zero Fill |
Raw Data Start VA および Raw Data End VA フィールドで区切られた初期化されたデータを超える、テンプレートのサイズ (バイト単位)。 テンプレートの合計サイズは、イメージ ファイル内の TLS データの合計サイズと同じである必要があります。 0 の埋め込みは、初期化された 0 以外のデータの後に続くデータの量です。 |
| 20/36 |
4 |
特性 |
この 4 ビット [23:20] には、配置情報が記述されます。 使用できる値は、IMAGE_SCN_ALIGN_* として定義されたもので、オブジェクト ファイル内のセクションの配置を記述するためにも使用されます。 他の 28 ビットは将来利用するために予約されています。 |
TLS コールバック関数
このプログラムでは、TLS データ オブジェクトの追加の初期化と終了をサポートする 1 つ以上の TLS コールバック関数を提供できます。 このようなコールバック関数の一般的な用途は、オブジェクトのコンストラクターとデストラクターの呼び出しです。
通常は複数のコールバック関数はありませんが、必要に応じてコールバック関数を追加できるように、コールバックは配列として実装されます。 複数のコールバック関数がある場合、各関数は、そのアドレスが配列内で示される順序で呼び出されます。 配列の終わりは null ポインターです。 空のリストも完全に有効です (コールバックはサポートされません)。この場合、コールバック配列には 1 つのメンバーである null ポインターがあります。
コールバック関数のプロトタイプ (PIMAGE_TLS_CALLBACK 型のポインターによって指し示される) には、DLL エントリ ポイント関数と同じパラメーターがあります。
typedef VOID
(NTAPI *PIMAGE_TLS_CALLBACK) (
PVOID DllHandle,
DWORD Reason,
PVOID Reserved
);
Reserved パラメーターは 0 に設定する必要があります。 Reason パラメーターは次の値を取ることができます。
| 設定 | 値 | 説明 |
|---|---|---|
| DLL_PROCESS_ATTACH |
1 |
最初のスレッドを含む新しいプロセスが開始されました。 |
| DLL_THREAD_ATTACH |
2 |
新しいスレッドが作成されました。 この通知は、最初のスレッド以外のすべてのユーザーに送信されます。 |
| DLL_THREAD_DETACH |
3 |
スレッドが終了しようとしています。 この通知は、最初のスレッド以外のすべてのユーザーに送信されます。 |
| DLL_PROCESS_DETACH |
0 |
元のスレッドを含めて、プロセスが終了しようとしています。 |
読み込み構成構造体 (イメージのみ)
読み込み構成構造体 (IMAGE_LOAD_CONFIG_DIRECTORY) は、以前は、Windows NT オペレーティング システム自体で非常に限られたケースにおいて、イメージのファイル ヘッダーまたはオプションのヘッダーで記述するには難しすぎるか長すぎる、さまざまな機能を記述するために使用されていました。 Microsoft リンカーの現在のバージョンおよび Windows XP 以降のバージョンの Windows では、この構造体の新しいバージョンを、予約済みの SEH テクノロジを含む 32 ビット x86 ベースのシステムに使用します。 これにより、オペレーティング システムが例外のディスパッチ中に使用する安全な構造化例外ハンドラーの一覧が提供されます。 ハンドラー アドレスがイメージの VA 範囲内にあり、予約済み SEH 対応としてマークされている場合 (つまり、前述のように、オプションのヘッダーの DllCharacteristics フィールドでIMAGE_DLLCHARACTERISTICS_NO_SEH がクリアされている)、ハンドラーは、そのイメージの既知の安全なハンドラーの一覧に含まれている必要があります。 そうでないと、オペレーティング システムはアプリケーションを終了します。 これは、オペレーティング システムを制御するために過去に用いられていた "x86 例外ハンドラーの乗っ取り" の悪用を防ぐのに役立ちます。
Microsoft リンカーによって、既定の読み込み構成構造体が自動的に提供され、予約済みの SEH データが含まれます。 ユーザー コードによって読み込み構成構造体が既に提供されている場合は、この新しい予約済み SEH フィールドが含まれている必要があります。 そうでないと、リンカーは予約済み SEH データを含めることができないため、イメージは予約済み SEH を含んでいるとしてマークされません。
読み込み構成ディレクトリ
事前予約済みの SEH 読み込み構成構造体のデータ ディレクトリ エントリでは、ロード構成構造体の特定のサイズを指定する必要があります。これは、オペレーティング システム ローダーによって常に特定の値が想定されるためです。 この点に関して、サイズは実際にはバージョン チェックにすぎません。 Windows XP および以前のバージョンの Windows との互換性を保つために、x86 イメージのサイズを 64 にする必要があります。
読み込み構成レイアウト
ロード構成構造体には、32 ビットおよび 64 ビット PE ファイルについて、次のレイアウトがあります。
| Offset | サイズ | フィールド | 説明 |
|---|---|---|---|
| 0 |
4 |
特性 |
ファイルの属性を示すフラグ。現在は未使用。 |
| 4 |
4 |
TimeDateStamp |
日付と時刻のスタンプ値。 この値は、システム クロックに従って、1970 年 1 月 1 日の午前 0 時 (00:00:00) からの経過秒数で表されます。 タイム スタンプは、C ランタイム (CRT) の時刻関数を使用して出力できます。 |
| 8 |
2 |
MajorVersion |
メジャー バージョン番号。 |
| 10 |
2 |
MinorVersion |
マイナー バージョン番号。 |
| 12 |
4 |
GlobalFlagsClear |
ローダーがプロセスを開始すると、このプロセスに対してクリアされるグローバル ローダー フラグ。 |
| 16 |
4 |
GlobalFlagsSet |
ローダーがプロセスを開始すると、このプロセスに対して設定されるグローバル ローダー フラグ。 |
| 20 |
4 |
CriticalSectionDefaultTimeout |
破棄される、このプロセスの重要なセクションに使用される既定のタイムアウト値。 |
| 24 |
4/8 |
DeCommitFreeBlockThreshold |
システムに返される前に解放する必要があるメモリ (バイト単位)。 |
| 28/32 |
4/8 |
DeCommitTotalFreeThreshold |
空きメモリの合計容量 (バイト単位)。 |
| 32/40 |
4/8 |
LockPrefixTable |
[x86 のみ] 単一プロセッサ マシンで NOP に置き換えることができるように LOCK プレフィックスが使用されるアドレスの VA 一覧。 |
| 36/48 |
4/8 |
MaximumAllocationSize |
最大割り当てサイズ (バイト単位)。 |
| 40/56 |
4/8 |
VirtualMemoryThreshold |
仮想メモリの最大サイズ (バイト単位)。 |
| 44/64 |
4/8 |
ProcessAffinityMask |
このフィールドを 0 以外の値に設定すると、プロセスの起動時にこの値を使用して SetProcessAffinityMask が呼び出されます (.exeのみ) |
| 48/72 |
4 |
ProcessHeapFlags |
HeapCreate 関数の最初の引数に対応するプロセス ヒープ フラグ。 これらのフラグは、プロセスの起動時に作成されるプロセス ヒープに適用されます。 |
| 52/76 |
2 |
CSDVersion |
サービス パックのバージョン識別子。 |
| 54/78 |
2 |
予約済み |
ゼロを指定してください。 |
| 56/80 |
4/8 |
EditList |
システムで使用するために予約されています。 |
| 60/88 |
4/8 |
SecurityCookie |
Visual C++ または GS の実装で使用される Cookie へのポインター。 |
| 64/96 |
4/8 |
SEHandlerTable |
[x86 のみ] イメージ内の有効な一意の SE ハンドラーごとの RVA の並べ替え済みテーブルの VA。 |
| 68/104 |
4/8 |
SEHandlerCount |
[x86 のみ] テーブル内の一意のハンドラーの数。 |
| 72/112 |
4/8 |
GuardCFCheckFunctionPointer |
制御フロー ガードのチェック関数ポインターが格納される VA。 |
| 76/120 |
4/8 |
GuardCFDispatchFunctionPointer |
制御フロー ガードのディスパッチ関数ポインターが格納される VA。 |
| 80/128 |
4/8 |
GuardCFFunctionTable |
イメージ内の各制御フロー ガード関数の RVA の並べ替え済みテーブルの VA。 |
| 84/136 |
4/8 |
GuardCFFunctionCount |
上のテーブルの一意の RVA の数。 |
| 88/144 |
4 |
GuardFlags |
制御フロー ガード関連のフラグ。 |
| 92/148 |
12 |
CodeIntegrity |
コードの整合性情報。 |
| 104/160 |
4/8 |
GuardAddressTakenIatEntryTable |
制御フロー ガードのアドレスを取得した IAT テーブルが格納される VA。 |
| 108/168 |
4/8 |
GuardAddressTakenIatEntryCount |
上のテーブルの一意の RVA の数。 |
| 112/176 |
4/8 |
GuardLongJumpTargetTable |
制御フロー ガードのロング ジャンプ ターゲット テーブルが格納される VA。 |
| 116/184 |
4/8 |
GuardLongJumpTargetCount |
上のテーブルの一意の RVA の数。 |
GuardFlags フィールドには、次のフラグとサブフィールドの 1 つ以上の組み合わせが含まれています。
モジュールは、システム提供のサポートを使用して制御フローの整合性チェックを実行します。
#define IMAGE_GUARD_CF_INSTRUMENTED 0x00000100モジュールは、制御フローと書き込みの整合性チェックを実行します。
#define IMAGE_GUARD_CFW_INSTRUMENTED 0x00000200モジュールには、有効な制御フロー ターゲット メタデータが含まれています。
#define IMAGE_GUARD_CF_FUNCTION_TABLE_PRESENT 0x00000400モジュールでは、/GS セキュリティ Cookie は使用されません。
#define IMAGE_GUARD_SECURITY_COOKIE_UNUSED 0x00000800モジュールでは、読み取り専用の遅延読み込み IAT がサポートされています。
#define IMAGE_GUARD_PROTECT_DELAYLOAD_IAT 0x00001000自由に再保護できる独自の .didat セクション (他に何も含まれません) 内の遅延読み込みインポート テーブル。
#define IMAGE_GUARD_DELAYLOAD_IAT_IN_ITS_OWN_SECTION 0x00002000モジュールには、抑制されたエクスポート情報が含まれています。 また、アドレス取得済みの IAT テーブルも読み込み構成に存在することを示しています。
#define IMAGE_GUARD_CF_EXPORT_SUPPRESSION_INFO_PRESENT 0x00004000モジュールにより、エクスポートの抑制が可能になります。
#define IMAGE_GUARD_CF_ENABLE_EXPORT_SUPPRESSION 0x00008000モジュールには longjmp ターゲット情報が含まれています。
#define IMAGE_GUARD_CF_LONGJUMP_TABLE_PRESENT 0x00010000制御フロー ガード関数テーブル エントリのストライド (つまり、テーブル エントリあたりの追加バイト数) を含むサブフィールドのマスク。
#define IMAGE_GUARD_CF_FUNCTION_TABLE_SIZE_MASK 0xF0000000
さらに、Windows SDK winnt.h ヘッダーでは、GuardFlags 値を右シフトして制御フロー ガード関数テーブル ストライドを右揃えするビット数について、このマクロを定義します。
#define IMAGE_GUARD_CF_FUNCTION_TABLE_SIZE_SHIFT 28
.rsrc セクション
リソースには、複数レベルのバイナリ並べ替えツリー構造によってインデックスが付けられます。 一般的な設計では、2**31 レベルを含めることができます。 ただし、慣例により、Windows では、
- 型、名前、言語の 3 つのレベルが使用されます。
一連のリソース ディレクトリ テーブルは、すべてのレベルを次のように関連付けます。各ディレクトリ テーブルの後に、そのレベル (型、名前、または言語レベル) の名前または識別子 (ID) と、データ記述または別のディレクトリ テーブルのアドレスを指定する一連のディレクトリ エントリが続きます。 アドレスがデータの説明を指している場合、データはツリーのリーフです。 アドレスが別のディレクトリ テーブルを指している場合、そのテーブルには 1 つ下のレベルのディレクトリ エントリがリストされます。
リーフの型、名前、言語 ID は、リーフに到達するためにディレクトリ テーブルを通じて取得されるパスによって決まります。 最初のテーブルは型 ID を決定し、2 番目のテーブル (最初のテーブルのディレクトリ エントリによって示される) は名前 ID を決定し、3 番目のテーブルは言語 ID を決定します。
.rsrc セクションの一般的な構造は次のとおりです。
| Data | 説明 |
|---|---|
| Resource Directory Tables (および Resource Directory Entries) |
一連のテーブル (ツリー内のノードのグループごとに 1 つ)。 すべての最上位 (型) ノードが最初のテーブルにリストされます。 このテーブルのエントリは、第 2 レベルのテーブルを指します。 それぞれの第 2 レベルのツリーの型 ID は同じですが、名前 ID は異なります。 第 3 レベルのツリーの型 ID と名前 ID は同じですが、言語 ID は異なります。 各テーブルの直後にディレクトリ エントリが続きます。各エントリには、名前または数値識別子と、データ記述または 1 つ下のレベルのテーブルへのポインターがあります。 |
| Resource Directory Strings |
ディレクトリ エントリによって指し示される文字列データとして機能する 2 バイト配置 Unicode 文字列。 |
| Resource Data Description |
テーブルによって指し示されるレコードの配列。リソース データの実際のサイズと場所を記述します。 これらのレコードは、リソース説明ツリーのリーフです。 |
| リソース データ |
リソース セクションの生データ。 Resource Data Descriptions フィールドのサイズと場所の情報により、リソース データの個々の領域を区切ります。 |
リソース ディレクトリ テーブル
各リソース ディレクトリ テーブルの形式は次のとおりです。 このデータ構造体はテーブルの見出しと見なす必要があります。テーブルは実際には、ディレクトリ エントリ (セクション 6.9.2「リソース ディレクトリ エントリ」で説明) とこちらの構造体で構成されているためです。
| Offset | サイズ | フィールド | 説明 |
|---|---|---|---|
| 0 |
4 |
特性 |
リソース フラグ。 このフィールドは将来使用するために予約されています。 現在は 0 に設定されています。 |
| 4 |
4 |
Time/Date Stamp |
リソース コンパイラによってリソース データが作成された時刻。 |
| 8 |
2 |
メジャー バージョン |
ユーザーによって設定されるメジャー バージョン番号。 |
| 10 |
2 |
マイナー バージョン |
ユーザーによって設定されるマイナー バージョン番号。 |
| 12 |
2 |
Number of Name Entries |
テーブルの直後に続くディレクトリ エントリの数。(テーブルのレベルに応じて) 文字列を使用して、型、名前、または言語のエントリを識別します。 |
| 14 |
2 |
Number of ID Entries |
名前エントリの直後に続くディレクトリ エントリの数。型、名前、言語のエントリに数値 ID を使用します。 |
リソース ディレクトリ エントリ
ディレクトリ エントリは、テーブルの行を構成します。 各リソース ディレクトリ エントリの形式は次のとおりです。 エントリが名前または ID エントリであるかは、リソース ディレクトリ テーブルによって示されます。このテーブルは、後に続く名前および ID エントリの数を示します (テーブルのすべての名前エントリがすべての ID エントリの前に置かれます)。 テーブルのすべてのエントリは昇順で (名前エントリは大文字と小文字を区別する文字列によって、ID エントリは数値によって) 並べ替えられます。 オフセットは、IMAGE_DIRECTORY_ENTRY_RESOURCE DataDirectory 内のアドレスに対して相対的です。 詳細については、「PE 内のピアリング: Win32 移植可能な実行可能ファイル形式の概要」を参照してください。
| Offset | サイズ | フィールド | 説明 |
|---|---|---|---|
| 0 |
4 |
Name Offset |
テーブルのレベルに応じて、型、名前、または言語 ID エントリを指定する文字列のオフセット。 |
| 0 |
4 |
整数 ID |
型、名前、または言語 ID エントリを識別する 32 ビットの整数。 |
| 4 |
4 |
Data Entry Offset |
上位ビット 0。 リソース データ エントリ (リーフ) のアドレス。 |
| 4 |
4 |
Subdirectory Offset |
上位ビット 1。 下位 31 ビットは、別のリソース ディレクトリ テーブル (1 つ下のレベル) のアドレスです。 |
リソース ディレクトリ文字列
リソース ディレクトリ文字列領域は、ワード配置された Unicode 文字列で構成されます。 これらの文字列は、最後のリソース ディレクトリ エントリの後、かつ最初のリソース データ エントリの前にまとめて格納されます。 これにより、これらの可変長文字列が固定サイズのディレクトリ エントリの配置に対して与える影響を最小限に抑えられます。 各リソース ディレクトリ文字列の形式は次のとおりです。
| Offset | サイズ | フィールド | 説明 |
|---|---|---|---|
| 0 |
2 |
長さ |
長さフィールド自体を含まない、文字列のサイズ。 |
| 2 |
変数 |
Unicode String |
ワード配置された可変長の Unicode 文字列データ。 |
リソース データエントリ
各リソース データ エントリは、リソース データ領域の生データの実際の単位を記述します。 リソース データ エントリの形式は次のとおりです。
| Offset | サイズ | フィールド | 説明 |
|---|---|---|---|
| 0 |
4 |
Data RVA |
リソース データ領域のリソース データの単位のアドレス。 |
| 4 |
4 |
サイズ |
Data RVA フィールドが指すリソース データのサイズ (バイト単位)。 |
| 8 |
4 |
codepage |
リソース データ内のコード ポイント値をデコードするために使用されるコード ページ。 通常、コード ページは Unicode コード ページです。 |
| 12 |
4 |
予約済み。0 である必要があります。 |
.cormeta セクション (オブジェクトのみ)
CLR メタデータは、このセクションに格納されます。 これは、オブジェクト ファイルにマネージド コードが含まれていることを示すために使用されます。 メタデータの形式は文書化されていませんが、メタデータを処理するために CLR インターフェイスに渡すことができます。
.sxdata セクション
オブジェクトの有効な例外ハンドラーは、そのオブジェクトの .sxdata セクションにリストされます。 このセクションは IMAGE_SCN_LNK_INFO としてマークされます。 インデックスごとに 4 バイトを使用して、有効な各ハンドラーの COFF シンボル インデックスが含まれています。
さらに、コンパイラは、値フィールドの LSB を 1 に設定して絶対シンボル "@feat.00" を出力することで、COFF オブジェクトを登録済み SEH としてマークします。 SEH ハンドラーが登録されていない COFF オブジェクトには "@feat.00" シンボルがありますが、.sxdata セクションはありません。
アーカイブ (ライブラリ) ファイルの形式
COFF アーカイブ形式は、オブジェクト ファイルのコレクションを格納するための標準的なメカニズムを提供します。 これらのコレクションは、プログラミング ドキュメントでは一般にライブラリと呼ばれます。
アーカイブの最初の 8 バイトは、ファイル署名で構成されます。 アーカイブの残りの部分は、次のように一連のアーカイブ メンバーで構成されます。
1 番目と 2 番目のメンバーは "リンカー メンバー" です。これらの各メンバーは、「インポート名の種類」セクションで説明されているように、独自の形式を持ちます。 通常、リンカーはこれらのアーカイブ メンバーに情報を配置します。 リンカー メンバーには、アーカイブのディレクトリが含まれています。
3 番目のメンバーは "longnames" メンバーです。 このオプションのメンバーは、一連の null で終わる ASCII 文字列で構成されており、各文字列は別のアーカイブ メンバーの名前です。
アーカイブの残りの部分は、標準 (オブジェクト ファイル) メンバーで構成されます。 これらの各メンバーには、1 つのオブジェクト ファイルの内容全体が含まれます。
アーカイブ メンバー ヘッダーは、各メンバーの前にあります。 次の一覧は、アーカイブの一般的な構造を示しています。
| 署名: "!<arch>\n" |
|---|
| ヘッダー |
|---|
| 1 番目のリンカー メンバー |
| ヘッダー |
|---|
| 2 番目のリンカー メンバー |
| ヘッダー |
|---|
| longnames メンバー |
| ヘッダー |
|---|
| OBJ ファイル 1 の内容 (COFF 形式) |
| ヘッダー |
|---|
| OBJ ファイル 2 の内容 (COFF 形式) |
...
| ヘッダー |
|---|
| OBJ ファイル N の内容 (COFF 形式) |
アーカイブ ファイルの署名
アーカイブ ファイルの署名により、ファイルの種類が識別されます。 アーカイブ ファイルを入力として受け取るすべてのユーティリティ (リンカーなど) は、この署名を読み取ってファイルの種類をチェックできます。 シグネチャは次の ASCII 文字で構成され、改行 (\n) 文字を除き、下の各文字が文字どおり表されます。
!<arch>\n
Windows SDK winnt.h ヘッダーは、次のマクロを定義します。
#define IMAGE_ARCHIVE_START_SIZE 8
#define IMAGE_ARCHIVE_START "!<arch>\n"
#define IMAGE_ARCHIVE_END "`\n"
#define IMAGE_ARCHIVE_PAD "\n"
#define IMAGE_ARCHIVE_LINKER_MEMBER "/ "
#define IMAGE_ARCHIVE_LONGNAMES_MEMBER "// "
#define IMAGE_ARCHIVE_HYBRIDMAP_MEMBER "/<HYBRIDMAP>/ "
アーカイブ メンバー ヘッダー
各メンバー (リンカー、longnames、またはオブジェクト ファイル メンバー) の前にヘッダーがあります。 アーカイブ メンバー ヘッダーの形式は次のとおりです。各フィールドは、左揃えの ASCII テキスト文字列であり、フィールドの終わりまでスペースが埋め込まれます。 これらのフィールドには終端の null 文字はありません。
各メンバー ヘッダーは、前のアーカイブ メンバーの末尾の後の最初の偶数アドレスで開始されます。1 バイトの '\n' (IMAGE_ARCHIVE_PAD) をアーカイブ メンバーの後に挿入して、次のメンバーを偶数アドレスで開始できます。
| Offset | サイズ | フィールド | 説明 |
|---|---|---|---|
| 0 |
16 |
名前 |
アーカイブ メンバーの名前。名前の終わりにスラッシュ (/) が追加されます。 最初の文字がスラッシュの場合、次の表に示すように、名前には特別な意味があります。 |
| 16 |
12 |
Date |
アーカイブ メンバーが作成された日時。1970 年 1 月 1 日 UCT からの秒数の ASCII 10 進数表現です。 |
| 28 |
6 |
User ID |
ユーザー ID の ASCII 10 進数表現。 このフィールドには、Microsoft ツールによってすべて空白が出力されるため、Windows プラットフォームでは意味のある値は含まれません。 |
| 34 |
6 |
グループ ID |
グループ ID の ASCII 10 進数表現。 このフィールドには、Microsoft ツールによってすべて空白が出力されるため、Windows プラットフォームでは意味のある値は含まれません。 |
| 40 |
8 |
モード |
メンバーのファイル モードの ASCII 8 進数表現。 これは、C ランタイム関数 _wstat からの ST_MODE 値です。 |
| 48 |
10 |
サイズ |
ヘッダーのサイズを含まない、アーカイブ メンバーの合計サイズの ASCII 10 進数表現。 |
| 58 |
2 |
End of Header |
C 文字列 "'\n" (IMAGE_ARCHIVE_END) の 2 バイト (0x60 0x0A)。 |
Name フィールドには、次の表に示すいずれかの形式があります。 前述のように、これらの各文字列は左揃えで、16 バイトのフィールド内の末尾にはスペースが埋め込まれます。
| Name フィールドの内容 | 説明 |
|---|---|
| name/ |
アーカイブ メンバーの名前。 |
| / |
このアーカイブ メンバーは、2 つのリンカー メンバーのいずれかです。 どちらのリンカー メンバーもこの名前を持ちます。 |
| // |
このアーカイブ メンバーは longnames メンバーであり、一連の null で終わる ASCII 文字列で構成されます。 longnames メンバーは 3 番目のアーカイブ メンバーであり、オプションです。 |
| /n |
アーカイブ メンバーの名前は、longnames メンバー内のオフセット n にあります。 数値 n はオフセットの 10 進数表現です。 たとえば、"/26" は、アーカイブ メンバーの名前が longnames メンバーの内容の先頭を越えて 26 バイト先にあることを示します。 |
１ 番目のリンカー メンバー
最初のリンカー メンバーの名前は "/" (IMAGE_ARCHIVE_LINKER_MEMBER)。 １ 番目のリンカー メンバーは、下位互換性のために含まれています。 現在のリンカーでは使用されませんが、その形式は正しくなければなりません。 このリンカー メンバーは、2 番目のリンカー メンバーと同様に、シンボル名のディレクトリを提供します。 この情報は、シンボルごとに、シンボルを含むアーカイブ メンバーを検索する場所を示します。
１ 番目のリンカー メンバーの形式は次のとおりです。 この情報は、ヘッダーの後に示されます。
| Offset | サイズ | フィールド | 説明 |
|---|---|---|---|
| 0 |
4 |
Number of Symbols |
インデックス付きシンボルの数を含む符号なし long 型。 この数値は、ビッグ エンディアン形式で格納されます。 通常、オブジェクト ファイル メンバーごとに 1 つ以上の外部シンボルが定義されます。 |
| 4 |
4 * n |
オフセット |
アーカイブ メンバー ヘッダーへのファイル オフセットの配列。n は Number of Symbols フィールドと等しいです。 配列内の各数値は、ビッグ エンディアン形式で格納された符号なし long 型です。 文字列テーブルで名前が付けられているシンボルごとに、オフセット配列内の対応する要素によって、そのシンボルを含むアーカイブ メンバーの場所が指定されます。 |
| * |
* |
String Table |
ディレクトリ内のすべてのシンボルに名前を付ける、一連の null で終わる文字列。 各文字列は、前の文字列の null 文字の直後から開始されます。 文字列の数は、Number of Symbols フィールドの値と等しくなければなりません。 |
オフセット配列内の要素は昇順に並べる必要があります。 これは、文字列テーブル内のシンボルをアーカイブ メンバーの順序に従って並べる必要があることを意味します。 たとえば、最初のオブジェクト ファイル メンバーのすべてのシンボルは、2 番目のオブジェクト ファイル内のシンボルの前にリストする必要があります。
2 番目のリンカー メンバー
最初のリンカー メンバーと同様に、2 番目のリンカー メンバーの名前は "/" です (IMAGE_ARCHIVE_LINKER_MEMBER)。 どちらのリンカー メンバーもシンボルのディレクトリとそれらを含むアーカイブ メンバーを提供しますが、2 番目のリンカー メンバーは、現在のすべてのリンカーによって 1 番目より優先して使用されます。 2 番目のリンカー メンバーにはシンボル名が辞書順で含まれており、これによって名前による検索を高速で行うことができます。
2 番目のメンバーの形式は次のとおりです。 この情報は、ヘッダーの後に示されます。
| Offset | サイズ | フィールド | 説明 |
|---|---|---|---|
| 0 |
4 |
Number of Members |
アーカイブ メンバーの数を含む符号なし long 型。 |
| 4 |
4 * m |
オフセット |
アーカイブ メンバー ヘッダーへのファイル オフセットの配列。昇順に並べられます。 各オフセットは、符号なし long 型です。 数値 m は Number of Members フィールドの値と等しいです。 |
| * |
4 |
Number of Symbols |
インデックス付きシンボルの数を含む符号なし long 型。 通常、オブジェクト ファイル メンバーごとに 1 つ以上の外部シンボルが定義されます。 |
| * |
2 * n |
Indices |
シンボル名をアーカイブ メンバー オフセットにマップする 1 から始まるインデックス (符号なし short 型) の配列。 数値 n は、Number of Symbols フィールドと等しいです。 文字列テーブルで名前が付けられたシンボルごとに、インデックス配列内の対応する要素によって、オフセット配列にインデックスが提供されます。 その後、オフセット配列によって、シンボルを含むアーカイブ メンバーの場所が提供されます。 |
| * |
* |
String Table |
ディレクトリ内のすべてのシンボルに名前を付ける、一連の null で終わる文字列。 各文字列は、前の文字列の null バイトの直後から開始されます。 文字列の数は、Number of Symbols フィールドの値と等しくなければなりません。 このテーブルには、すべてのシンボル名が辞書順に昇順でリストされます。 |
longnames メンバー
longnames メンバーの名前は "//" (IMAGE_ARCHIVE_LONGNAMES_MEMBER) です。 longnames メンバーは、一連のアーカイブ メンバー名の文字列です。 名前がここに示されるのは、Name フィールド (16 バイト) の領域が足りない場合のみです。 longnames メンバーはオプションです。 ヘッダーのみで空でも、ヘッダーもなしで完全に存在しなくても構いません。
文字列は null で終わります。 各文字列は、前の文字列の null バイトの直後から開始されます。
インポート ライブラリの形式
従来のインポート ライブラリ、つまり、あるイメージからのエクスポートを別のイメージで使用するために記述するライブラリは、通常、セクション 7 の「アーカイブ (ライブラリ) ファイルの形式」で説明されているレイアウトに従います。 主な違いは、インポート ライブラリ メンバーには実際のファイルではなく擬似オブジェクト ファイルが含まれていることです。各メンバーには、セクション 6.4 「.idata セクション」で説明されているインポート テーブルの作成に必要なセクションの提供内容が含まれています。リンカーによって、エクスポートするアプリケーションのビルド中にこのアーカイブが生成されます。
インポートのためのセクションの提供内容は、小さな情報セットから推測できます。 リンカーは、ライブラリの作成時に各メンバーのインポート ライブラリに完全で詳細な情報を生成することも、ライブラリには正規の情報のみを書き込み、アプリケーションが後で使用するときに必要なデータをその場で生成するようにすることもできます。
長い形式のインポート ライブラリでは、1 つのメンバーに次の情報が含まれます。
- アーカイブ メンバー ヘッダー
- ファイル ヘッダー
- セクション ヘッダー
- 各セクション ヘッダーに対応するデータ
- COFF シンボル テーブル
- 文字列
これに対し、短いインポート ライブラリは次のように記述されます。
- アーカイブ メンバー ヘッダー
- インポート ヘッダー
- null で終わるインポート名の文字列
- null で終わる DLL 名の文字列
これは、使用時にメンバーの内容全体を正確に再作成するのに十分な情報です。
インポート ヘッダー
インポート ヘッダーには、次のフィールドとオフセットが含まれています。
| Offset | サイズ | フィールド | 説明 |
|---|---|---|---|
| 0 |
2 |
Sig1 |
IMAGE_FILE_MACHINE_UNKNOWN にする必要があります。 詳細については、「マシンの種類」を参照してください。 |
| 2 |
2 |
Sig2 |
0xFFFF にする必要があります。 |
| 4 |
2 |
バージョン |
構造体のバージョン。 |
| 6 |
2 |
Machine |
ターゲット マシンの種類を識別する番号。 詳細については、「マシンの種類」を参照してください。 |
| 8 |
4 |
Time-Date Stamp |
ファイルが作成された日時。 |
| 12 |
4 |
Size Of Data |
ヘッダーに続く文字列のサイズ。 |
| 16 |
2 |
Ordinal/Hint |
Name Type フィールドの値によって決まるインポートの順序またはヒント。 |
| 18 |
2 ビット |
Type |
インポートの種類。 特定の値と説明については、「インポートの種類」を参照してください。 |
| 3 ビット |
Name Type |
インポート名の種類。 詳細については、「インポート名の種類」を参照してください。 |
|
| 11 ビット |
予約済み |
予約済み。0 である必要があります。 |
この構造体の後には、インポートされるシンボルの名前と、それが含まれる DLL を示す 2 つの null で終わる文字列が続きます。
インポートの種類
インポート ヘッダーの Type フィールドには、次の値が定義されています。
| 定数 | 値 | 説明 |
|---|---|---|
| IMPORT_OBJECT_CODE |
0 |
実行可能コード。 |
| IMPORT_OBJECT_DATA |
1 |
データ。 |
| IMPORT_OBJECT_CONST |
2 |
.def ファイルで CONST として指定されます。 |
これらの値は、そのデータにアクセスする必要がある場合に、ライブラリを使用するツールによって生成される必要があるセクションの提供内容を決定するために使用されます。
インポート名の種類
null で終わるインポート シンボル名は、その関連付けられているインポート ヘッダーの直後に続きます。 インポート ヘッダーの Name Type フィールドには、次の値が定義されています。 これらは、インポートを表す正しいシンボルを生成するために、名前がどのように使われるかを示します。
| 定数 | 値 | 説明 |
|---|---|---|
| IMPORT_OBJECT_ORDINAL | 0 | インポートは序数によって行われます。 これは、インポート ヘッダーの Ordinal/Hint フィールドの値がインポートの序数であることを示します。 この定数を指定しない場合、Ordinal/Hint フィールドは常にインポートのヒントとして解釈されます。 |
| IMPORT_OBJECT_NAME | 1 | インポート名はパブリック シンボル名と同じです。 |
| IMPORT_OBJECT_NAME_NOPREFIX | 2 | インポート名はパブリック シンボル名ですが、先頭の ?、@、またはオプションの _ はスキップされます。 |
| IMPORT_OBJECT_NAME_UNDECORATE | 3 | インポート名はパブリック シンボル名ですが、先頭の ?、@、またはオプションの _ はスキップされ、最初の @で切り捨てられます。 |
付録 A: Authenticode PE イメージ ハッシュの計算
イメージの整合性を検証するために、いくつかの属性証明書が使用されることが期待されています。 ただし、最も一般的なのは Authenticode 署名です。 Authenticode 署名を使用すると、PE イメージ ファイルの関連セクションがファイルの元の形式から一切変更されていないことを確認できます。 このタスクを実行するために、Authenticode 署名には PE イメージ ハッシュと呼ばれるものが含まれています
Authenticode PE イメージ ハッシュとは
Authenticode PE イメージ ハッシュ (略してファイル ハッシュ) は、ファイルの整合性に関連する小さな値を生成するという点で、ファイル チェックサムに似ています。 チェックサムは単純なアルゴリズムによって生成され、主にメモリの障害を検出するために使用されます。 つまり、ディスク上のメモリ ブロックに不良が生じ、そこに格納されている値が破損していないかどうかを検出するために使用されます。 ファイル ハッシュは、ファイルの破損も検出するという点でチェックサムに似ています。 ただし、ほとんどのチェックサム アルゴリズムとは異なり、ファイルを変更し、元の (変更されていない) 形式と同じファイル ハッシュ持つようにすることは非常に困難です。 つまり、チェックサムは破損につながる単純なメモリ障害を検出することを目的としていますが、ファイル ハッシュは、ウイルス、ハッカー、トロイの木馬プログラムなどによってもたらされるファイルに対する意図的で微妙な変更を検出するために使用できます。
Authenticode 署名では、ファイル ハッシュは、ファイルの署名者のみが知っている秘密キーを使用してデジタル署名されます。 ソフトウェア コンシューマーは、ファイルのハッシュ値を計算し、Authenticode デジタル署名に含まれる署名付きハッシュの値と比較して、ファイルの整合性を確認できます。 ファイル ハッシュが一致しない場合は、PE イメージ ハッシュの対象となるファイルの一部が変更されています。
Authenticode PE イメージ ハッシュの対象
PE イメージ ハッシュの計算にイメージ ファイルのすべてのデータを含めることは不可能であるか、望ましくありません。 単に望ましくない特性がもたらされるだけの場合もありますが (たとえば、デバッグ情報を一般公開されたファイルから削除できないなど)、単に不可能な場合もあります。 たとえば、Authenticode 署名にイメージ ファイル内のすべての情報を含め、その PE イメージ ハッシュを含む Authenticode 署名を PE イメージに挿入し、その後、すべてのイメージ ファイル データを計算に含めて同一の PE イメージ ハッシュを生成できるようにすることは不可能です。これは、ファイルには元々存在しなかった Authenticode 署名が含まれているためです。
Authenticode PE イメージ ハッシュを生成するプロセス
このセクションでは、PE イメージ ハッシュの計算方法と、Authenticode 署名を無効にせずに変更できる PE イメージの部分について説明します。
注意
特定のファイルの PE イメージ ハッシュは、ハッシュされたファイル内に属性証明書を含めることなく、別のカタログ ファイルに含めることができます。 これは、実際には Authenticode 署名を含まない PE イメージを変更することで、Authenticode 署名付きカタログ ファイル内の PE イメージ ハッシュを無効にすることが可能になるため有効です。
次の除外範囲を除き、セクション テーブルで指定されている PE イメージのセクション内のすべてのデータが全体的にハッシュされます。
オプションのヘッダーの Windows 固有フィールドのファイル チェックサム フィールド。 このチェックサムには、ファイル全体 (ファイル内の属性証明書を含む) が含まれます。 Authenticode 署名を挿入した後、チェックサムは元の値とは異なる可能性が高くなります。
属性証明書に関連する情報。 Authenticode 署名に関連する PE イメージの領域は、PE イメージ ハッシュの計算には含まれません。これは、イメージの全体的な整合性に影響を与えることなく、Authenticode 署名をイメージに追加したり、削除したりできるためです。 PE イメージの再署名やタイム スタンプの追加に依存するユーザー シナリオがあるため、これは問題ではありません。 Authenticode では、ハッシュ計算から次の情報が除外されます。
オプション ヘッダー データ ディレクトリの Certificate Table フィールド。
証明書テーブルと、その直前にリストされている Certificate Table フィールドが指す対応する証明書。
PE イメージ ハッシュを計算するために、Authenticode はセクション テーブルで指定されたセクションをアドレス範囲で並べ替え、結果のバイト シーケンスをハッシュして除外範囲を渡します。
最後のセクションの末尾を過ぎた情報。 最後のセクションを越えた領域 (最大オフセットで定義) はハッシュされません。 この領域には、一般的にデバッグ情報が含まれています。 デバッグ情報は通常、デバッガー向けのアドバイスと見なされ、実行可能プログラムの実際の整合性には影響しません。 製品が提供された後にイメージからデバッグ情報を削除することは文字通り可能であり、プログラムの機能には影響しません。 実際、これはディスクを節約する手段として行われることがあります。 PE イメージの指定されたセクションに含まれるデバッグ情報は、Authenticode 署名を無効にしないと削除できないことに注意してください。
Windows プラットフォーム SDK で提供されている makecert および signtool ツールを使用して、Authenticode 署名の作成と検証を試すことができます。 詳細については、下の「リファレンス」を参照してください。
リファレンス
Windows 用のダウンロードとツール (Windows SDK を含む)
フィードバック
フィードバックの送信と表示