🎢 👇🏼 🎳 x64アーキテクチャコードモデルについて 📇 🤛🏻 🤐

「どのコードモデルを使用すればよいですか？」 -x64アーキテクチャ用のコードを作成する際に頻繁に発生するが、あまり議論されない質問。ただし、これはかなり興味深い問題であり、コンパイラによって生成されたx64マシンコードを理解するには、コードモデルを理解しておくと役立ちます。さらに、最小の命令までのパフォーマンスが心配な場合は、コードモデルの選択も最適化に影響します。

このトピックに関する情報は、ネットワークやその他のどこにもありません。利用可能なリソースの中で最も重要なのは公式のx64 ABIです。ここからダウンロードできます（以下、「ABI」と呼びます）。情報の一部は、上で見つけることができますman-pagesgcc... この記事の目的は、トピックに関するアクセシブルな推奨事項を提供し、関連する問題について議論し、作業で使用される適切なコードを通じていくつかの概念を実証することです。

重要な注意：この記事は初心者向けのチュートリアルではありません。知る前に、Cとアセンブラの強力なコマンド、およびx64アーキテクチャの基本的な知識を持っていることをお勧めします。

関連トピックに関する以前の投稿も参照してください：x86_x64がメモリをアドレス指定する方法

コードモデル。やる気を起こさせる部分

x64アーキテクチャでは、コードとデータの両方が、コマンド相対（またはx64専門用語を使用してRIP相対）アドレッシングモデルを通じて参照されます。これらのコマンドでは、RIPからのシフトは32ビットに制限されていますが、メモリまたはデータの一部をアドレス指定しようとしたときに、たとえば2ギガバイトを超えるプログラムを使用している場合など、チームが単に32ビットシフトを行わない場合があります。

この問題を解決する1つの方法は、RIP相対アドレッシングモードを完全に破棄して、すべてのデータおよびコード参照に対して完全な64ビットシフトを優先することです。ただし、このステップは非常に費用がかかります。非常に大きなプログラムとライブラリの（かなりまれな）ケースをカバーするには、コード全体で最も単純な操作でさえ、通常より多くのコマンドが必要になります。

したがって、コードモデルはトレードオフになります。[1]コードモデルは、プログラマーとコンパイラーの間の正式な合意であり、プログラマーは、現在コンパイルされているオブジェクトモジュールが該当する予定のプログラム（複数の場合もある）のサイズに関する意図を指定します。[2]コードモデルが必要なのは、プログラマがコンパイラに「このオブジェクトモジュールは小さなプログラムに入るだけなので、高速なRIP相対アドレッシングモードを使用できるため、心配する必要がない」ということです。一方、コンパイラーに次のように伝える可能性があります。「このモジュールを大きなプログラムにリンクするので、完全な64ビットシフトでゆっくりと安全な絶対アドレッシングモードを使用してください。」

この記事が伝えること

上記の2つのシナリオ、小さなコードモデルと大きなコードモデルについて説明します。最初のモデルは、オブジェクトユニット内のすべてのコードとデータ参照に32ビットの相対オフセットで十分であることをコンパイラーに伝えます。2番目は、コンパイラーが絶対64ビット・アドレッシング・モードを使用することを要求しています。さらに、中間バージョン、いわゆるミドルコードモデルもあります。

これらの各コードモデルは、独立したPICと非PICのバリエーションで提示され、6つそれぞれについて説明します。

元のCの例

この記事で説明する概念を示すために、以下のCプログラムを使用して、さまざまなコードモデルでコンパイルします。ご覧のとおり、この関数mainは4つの異なるグローバル配列と1つのグローバル関数にアクセスします。配列は、サイズと可視性の2つのパラメーターが異なります。サイズは平均的なコードモデルを説明するために重要であり、大小のモデルを扱う場合には必要ありません。可視性はPICコードモデルの操作にとって重要であり、静的（ソースファイルでのみ表示）またはグローバル（プログラムにリンクされているすべてのオブジェクトに対する可視性）のいずれかです。

int global_arr[100] = {2, 3};
static int static_arr[100] = {9, 7};
int global_arr_big[50000] = {5, 6};
static int static_arr_big[50000] = {10, 20};

int global_func(int param)
{
    return param * 10;
}

int main(int argc, const char* argv[])
{
    int t = global_func(argc);
    t += global_arr[7];
    t += static_arr[7];
    t += global_arr_big[7];
    t += static_arr_big[7];
    return t;
}

gccオプション値としてコードモデルを使用します-mcmodel。さらに、-fpicPICコンパイルはフラグで設定できます。

PICを使用した大規模なコードモデルによるオブジェクトモジュールへのコンパイルの例：

> gcc -g -O0 -c codemodel1.c -fpic -mcmodel=large -o codemodel1_large_pic.o

小さなコードモデル

小さなコードモデルでのman gccからの引用の翻訳：

-mcmodel = small

小さなモデルのコードの生成：プログラムとそのシンボルは、アドレス空間の下位2ギガバイトに配置する必要があります。ポインタのサイズは64ビットです。プログラムは静的にも動的にも構築できます。これは基本的なコードモデルです。

言い換えると、コンパイラは、コード内のコマンドからの32ビットRIP相対オフセットを介してコードとデータにアクセスできると安全に想定できます。PIC以外の小さなコードモデルでコンパイルしたCプログラムの逆アセンブルされた例を見てみましょう。

> objdump -dS codemodel1_small.o
[...]
int main(int argc, const char* argv[])
{
  15: 55                      push   %rbp
  16: 48 89 e5                mov    %rsp,%rbp
  19: 48 83 ec 20             sub    $0x20,%rsp
  1d: 89 7d ec                mov    %edi,-0x14(%rbp)
  20: 48 89 75 e0             mov    %rsi,-0x20(%rbp)
    int t = global_func(argc);
  24: 8b 45 ec                mov    -0x14(%rbp),%eax
  27: 89 c7                   mov    %eax,%edi
  29: b8 00 00 00 00          mov    $0x0,%eax
  2e: e8 00 00 00 00          callq  33 <main+0x1e>
  33: 89 45 fc                mov    %eax,-0x4(%rbp)
    t += global_arr[7];
  36: 8b 05 00 00 00 00       mov    0x0(%rip),%eax
  3c: 01 45 fc                add    %eax,-0x4(%rbp)
    t += static_arr[7];
  3f: 8b 05 00 00 00 00       mov    0x0(%rip),%eax
  45: 01 45 fc                add    %eax,-0x4(%rbp)
    t += global_arr_big[7];
  48: 8b 05 00 00 00 00       mov    0x0(%rip),%eax
  4e: 01 45 fc                add    %eax,-0x4(%rbp)
    t += static_arr_big[7];
  51: 8b 05 00 00 00 00       mov    0x0(%rip),%eax
  57: 01 45 fc                add    %eax,-0x4(%rbp)
    return t;
  5a: 8b 45 fc                mov    -0x4(%rbp),%eax
}
  5d: c9                      leaveq
  5e: c3                      retq

ご覧のとおり、すべてのアレイへのアクセスは、RIP相対シフトを使用して同じ方法で編成されています。ただし、コードのシフトは0です。これは、コンパイラがデータセグメントの配置場所を知らないため、そのようなアクセスごとに再配置が作成されるためです。

> readelf -r codemodel1_small.o

Relocation section '.rela.text' at offset 0x62bd8 contains 5 entries:
  Offset          Info           Type           Sym. Value    Sym. Name + Addend
00000000002f  001500000002 R_X86_64_PC32     0000000000000000 global_func - 4
000000000038  001100000002 R_X86_64_PC32     0000000000000000 global_arr + 18
000000000041  000300000002 R_X86_64_PC32     0000000000000000 .data + 1b8
00000000004a  001200000002 R_X86_64_PC32     0000000000000340 global_arr_big + 18
000000000053  000300000002 R_X86_64_PC32     0000000000000000 .data + 31098

へのアクセスを完全にデコードしてみましょうglobal_arr。私たちが関心のある逆アセンブルされたセグメントは次のとおりです。

  t += global_arr[7];
36:       8b 05 00 00 00 00       mov    0x0(%rip),%eax
3c:       01 45 fc                add    %eax,-0x4(%rbp)

RIP相対アドレッシングは次のコマンドに関連しているため、シフトはmov0x3sに対応するようにコマンドにパッチする必要があります。 2番目の再配置に関心があります。これはアドレスR_X86_64_PC32のオペランドmovを指し0x38、次のことを意味します。シンボルの値を取得し、項を追加して、再配置によって示されるシフトを差し引きます。すべてを正しく計算すると、結果が次のコマンドとglobal_arr、およびの間に相対シフトをどのように配置するかがわかります01。01「配列の7番目のint」を意味するため（x64アーキテクチャでは、それぞれのサイズintは4バイトです）、この相対的なシフトが必要です。したがって、RIP相対アドレッシングを使用すると、コマンドはを正しく参照しglobal_arr[7]ます。

次の点にも注目してください。static_arrここでのアクセスコマンドは似ていますが、そのリダイレクトでは別のシンボルを使用しているため、特定のシンボルではなくセクションをポイントしています.data。これはリンカのアクションによるもので、静的配列をセクション内の既知の場所に配置するため、配列を他の共有ライブラリと共有することはできません。その結果、リンカはこの再配置で状況を解決します。一方、global_arr別の共有ライブラリで使用（または上書き）できるため、すでにダイナミックローダーはへのリンクを処理する必要がありglobal_arrます。 [3]

最後に、への参照を見てみましょうglobal_func：

  int t = global_func(argc);
24:       8b 45 ec                mov    -0x14(%rbp),%eax
27:       89 c7                   mov    %eax,%edi
29:       b8 00 00 00 00          mov    $0x0,%eax
2e:       e8 00 00 00 00          callq  33 <main+0x1e>
33:       89 45 fc                mov    %eax,-0x4(%rbp)

オペランドcallqもRIP相対であるため、R_X86_64_PC32ここでの再配置は、global_funcへの実際の相対シフトをオペランドに配置するのと同じように機能します。

結論として、コードモデルが小さいため、コンパイラは将来のプログラムのすべてのデータとコードを32ビットシフトを通じて利用できると認識し、あらゆる種類のオブジェクトにアクセスするためのシンプルで効率的なコードを作成します。

大きなコードモデル

man gcc大きなコードモデルからの引用の翻訳：

-mcmodel = large大

規模モデル用のコードの生成：このモデルは、アドレスとセクションサイズに関する仮定を行いません。

mainPIC以外の大きなモデルを使用してコンパイルされた逆アセンブルされたコードの例：

int main(int argc, const char* argv[])
{
  15: 55                      push   %rbp
  16: 48 89 e5                mov    %rsp,%rbp
  19: 48 83 ec 20             sub    $0x20,%rsp
  1d: 89 7d ec                mov    %edi,-0x14(%rbp)
  20: 48 89 75 e0             mov    %rsi,-0x20(%rbp)
    int t = global_func(argc);
  24: 8b 45 ec                mov    -0x14(%rbp),%eax
  27: 89 c7                   mov    %eax,%edi
  29: b8 00 00 00 00          mov    $0x0,%eax
  2e: 48 ba 00 00 00 00 00    movabs $0x0,%rdx
  35: 00 00 00
  38: ff d2                   callq  *%rdx
  3a: 89 45 fc                mov    %eax,-0x4(%rbp)
    t += global_arr[7];
  3d: 48 b8 00 00 00 00 00    movabs $0x0,%rax
  44: 00 00 00
  47: 8b 40 1c                mov    0x1c(%rax),%eax
  4a: 01 45 fc                add    %eax,-0x4(%rbp)
    t += static_arr[7];
  4d: 48 b8 00 00 00 00 00    movabs $0x0,%rax
  54: 00 00 00
  57: 8b 40 1c                mov    0x1c(%rax),%eax
  5a: 01 45 fc                add    %eax,-0x4(%rbp)
    t += global_arr_big[7];
  5d: 48 b8 00 00 00 00 00    movabs $0x0,%rax
  64: 00 00 00
  67: 8b 40 1c                mov    0x1c(%rax),%eax
  6a: 01 45 fc                add    %eax,-0x4(%rbp)
    t += static_arr_big[7];
  6d: 48 b8 00 00 00 00 00    movabs $0x0,%rax
  74: 00 00 00
  77: 8b 40 1c                mov    0x1c(%rax),%eax
  7a: 01 45 fc                add    %eax,-0x4(%rbp)
    return t;
  7d: 8b 45 fc                mov    -0x4(%rbp),%eax
}
  80: c9                      leaveq
  81: c3                      retq

繰り返しになりますが、再配置を確認すると便利です。

Relocation section '.rela.text' at offset 0x62c18 contains 5 entries:
  Offset          Info           Type           Sym. Value    Sym. Name + Addend
000000000030  001500000001 R_X86_64_64       0000000000000000 global_func + 0
00000000003f  001100000001 R_X86_64_64       0000000000000000 global_arr + 0
00000000004f  000300000001 R_X86_64_64       0000000000000000 .data + 1a0
00000000005f  001200000001 R_X86_64_64       0000000000000340 global_arr_big + 0
00000000006f  000300000001 R_X86_64_64       0000000000000000 .data + 31080

コードとデータセクションのサイズを想定する必要がないため、大規模なコードモデルはかなり均一であり、すべてのデータへのアクセスを同じ方法で定義します。もう一度見てみましょうglobal_arr：

  t += global_arr[7];
3d:       48 b8 00 00 00 00 00    movabs $0x0,%rax
44:       00 00 00
47:       8b 40 1c                mov    0x1c(%rax),%eax
4a:       01 45 fc                add    %eax,-0x4(%rbp)

2つのチームがアレイから目的の値を取得する必要があります。最初のコマンドは絶対64ビットアドレスをに配置しますrax。これは、後で説明するように、アドレスになることがわかりますがglobal_arr、2番目のコマンドはワードを(rax) + 01にロードしeaxます。

それではでチームに焦点を当ててみましょう0x3d、movabs絶対64ビット版movx64アーキテクチャインチ完全な64ビット定数を直接レジスターにスローできます。逆アセンブルされたコードでは、この定数の値はゼロに等しいので、答えを求めるには再配置テーブルを使用する必要があります。その中で、次の値を使用R_X86_64_64して、アドレス0x3fでのオペランドの絶対再配置が見つかります。シンボルの値と加算値をシフトに戻します。言い換えると、rax絶対アドレスが含まれますglobal_arr。

呼び出し機能はどうですか？

  int t = global_func(argc);
24:       8b 45 ec                mov    -0x14(%rbp),%eax
27:       89 c7                   mov    %eax,%edi
29:       b8 00 00 00 00          mov    $0x0,%eax
2e:       48 ba 00 00 00 00 00    movabs $0x0,%rdx
35:       00 00 00
38:       ff d2                   callq  *%rdx
3a:       89 45 fc                mov    %eax,-0x4(%rbp)

atで関数を呼び出すmovabsコマンドに続くものはすでに知っています。対応する再配置を見て、データへのアクセスとどの程度類似しているかを確認してください。ご覧のとおり、大規模なコードモデルでは、コードとデータセクションのサイズ、および文字の最終的な配置についての仮定はありません。これは、「セーフトラック」の一種である、絶対64ビットステップによる文字を単に参照しています。ただし、小さなコードモデルと比較して、大きなモデルでは各文字に対して追加のコマンドを使用する必要があることに注意してください。これはセキュリティの代償です。callrdx

したがって、2つの完全に反対のモデルに出会いました：小さなコードモデルはすべてが下の2ギガバイトのメモリに収まると想定していますが、大きなモデルは何も不可能ではなく、すべての文字がどこにでもあると想定しています64ビットアドレス空間。2つの間のトレードオフは、中間コードモデルです。

中型コードモデル

前と同じように、からの引用の翻訳を見てみましょうman gcc：

-mcmodel=medium

: . . , -mlarge-data-threshold, bss . , .

小さなコードモデルと同様に、中間のモデルでは、コード全体が2ギガバイト以下に配置されていると想定しています。それにもかかわらず、データは、おそらく「ギガバイト」の下位2ギガバイトに配置され、メモリスペース「無制限」に無制限に分割されます。データは、定義により64キロバイトに等しい制限を超えると、大きなカテゴリに分類されます。

セクションから類推して、ビッグデータの平均コードモデルを扱うときに注意することも重要である.dataと.bss：、特別なセクションが作成されている.ldataと.lbss。これは、現在の記事のトピックのプリズムではそれほど重要ではありませんが、少しそれから逸脱します。この問題の詳細については、ABIを参照してください。

これらの配列が例に表示された理由が明らかになりました。_big：それらは、それぞれが200キロバイトのサイズである「ビッグデータ」を解釈するための中間モデルで必要です。以下に、分解の結果を示します。

int main(int argc, const char* argv[])
{
  15: 55                      push   %rbp
  16: 48 89 e5                mov    %rsp,%rbp
  19: 48 83 ec 20             sub    $0x20,%rsp
  1d: 89 7d ec                mov    %edi,-0x14(%rbp)
  20: 48 89 75 e0             mov    %rsi,-0x20(%rbp)
    int t = global_func(argc);
  24: 8b 45 ec                mov    -0x14(%rbp),%eax
  27: 89 c7                   mov    %eax,%edi
  29: b8 00 00 00 00          mov    $0x0,%eax
  2e: e8 00 00 00 00          callq  33 <main+0x1e>
  33: 89 45 fc                mov    %eax,-0x4(%rbp)
    t += global_arr[7];
  36: 8b 05 00 00 00 00       mov    0x0(%rip),%eax
  3c: 01 45 fc                add    %eax,-0x4(%rbp)
    t += static_arr[7];
  3f: 8b 05 00 00 00 00       mov    0x0(%rip),%eax
  45: 01 45 fc                add    %eax,-0x4(%rbp)
    t += global_arr_big[7];
  48: 48 b8 00 00 00 00 00    movabs $0x0,%rax
  4f: 00 00 00
  52: 8b 40 1c                mov    0x1c(%rax),%eax
  55: 01 45 fc                add    %eax,-0x4(%rbp)
    t += static_arr_big[7];
  58: 48 b8 00 00 00 00 00    movabs $0x0,%rax
  5f: 00 00 00
  62: 8b 40 1c                mov    0x1c(%rax),%eax
  65: 01 45 fc                add    %eax,-0x4(%rbp)
    return t;
  68: 8b 45 fc                mov    -0x4(%rbp),%eax
}
  6b: c9                      leaveq
  6c: c3                      retq

配列へのアクセスがどのように行われるかに注意してください。配列へのアクセスは_big大きなコードモデルのメソッドを経由し、他の配列へのアクセスは小さなモデルのメソッドを経由します。関数も小さなコードモデルメソッドを使用して呼び出されます。再配置は前の例と非常に似ているため、ここでは説明しません。

中間コードモデルは、大規模モデルと小規模モデルの間の巧みな妥協案です。プログラムコードが大きくなりすぎる可能性は低く[4]、静的にリンクされたデータの大きなチャンクのみが、おそらくある種の膨大なテーブル検索の一部として、2ギガバイトの制限を超えて移動できます。中間コードモデルは、このような大きなデータチャンクをフィルタリングして特別な方法で処理するため、関数と小さなシンボルのコードによる呼び出しは、小さなコードモデルと同じくらい効率的です。ラージモデルと同様に、ラージシンボルへのアクセスのみが、ラージモデルの完全な64ビットメソッドを使用するコードを必要とします。

小さなPICコードモデル

次に、コードモデルのPICバリアントを見てみましょう。前と同じように、小さなモデルから始めます。[5]以下は、小さなPICモデルでコンパイルされたコードの例です。

int main(int argc, const char* argv[])
{
  15:   55                      push   %rbp
  16:   48 89 e5                mov    %rsp,%rbp
  19:   48 83 ec 20             sub    $0x20,%rsp
  1d:   89 7d ec                mov    %edi,-0x14(%rbp)
  20:   48 89 75 e0             mov    %rsi,-0x20(%rbp)
    int t = global_func(argc);
  24:   8b 45 ec                mov    -0x14(%rbp),%eax
  27:   89 c7                   mov    %eax,%edi
  29:   b8 00 00 00 00          mov    $0x0,%eax
  2e:   e8 00 00 00 00          callq  33 <main+0x1e>
  33:   89 45 fc                mov    %eax,-0x4(%rbp)
    t += global_arr[7];
  36:   48 8b 05 00 00 00 00    mov    0x0(%rip),%rax
  3d:   8b 40 1c                mov    0x1c(%rax),%eax
  40:   01 45 fc                add    %eax,-0x4(%rbp)
    t += static_arr[7];
  43:   8b 05 00 00 00 00       mov    0x0(%rip),%eax
  49:   01 45 fc                add    %eax,-0x4(%rbp)
    t += global_arr_big[7];
  4c:   48 8b 05 00 00 00 00    mov    0x0(%rip),%rax
  53:   8b 40 1c                mov    0x1c(%rax),%eax
  56:   01 45 fc                add    %eax,-0x4(%rbp)
    t += static_arr_big[7];
  59:   8b 05 00 00 00 00       mov    0x0(%rip),%eax
  5f:   01 45 fc                add    %eax,-0x4(%rbp)
    return t;
  62:   8b 45 fc                mov    -0x4(%rbp),%eax
}
  65:   c9                      leaveq
  66:   c3                      retq

移転：

Relocation section '.rela.text' at offset 0x62ce8 contains 5 entries:
  Offset          Info           Type           Sym. Value    Sym. Name + Addend
00000000002f  001600000004 R_X86_64_PLT32    0000000000000000 global_func - 4
000000000039  001100000009 R_X86_64_GOTPCREL 0000000000000000 global_arr - 4
000000000045  000300000002 R_X86_64_PC32     0000000000000000 .data + 1b8
00000000004f  001200000009 R_X86_64_GOTPCREL 0000000000000340 global_arr_big - 4
00000000005b  000300000002 R_X86_64_PC32     0000000000000000 .data + 31098

大きなデータと小さなデータの違いは小さなコードモデルでは何の役割も果たさないため、PICを使用してコードを生成するときの重要なポイントであるローカル（静的）シンボルとグローバルシンボルの違いに焦点を当てます。

ご覧のとおり、静的配列用に生成されたコードとPIC以外の場合のコードに違いはありません。これは、x64アーキテクチャの利点の1つです。データへのIP相対アクセスのおかげで、少なくともシンボルへの外部アクセスが必要になるまで、ボーナスとしてPICを取得できます。すべてのコマンドと再配置は同じままなので、それらを再度処理する必要はありません。

グローバル配列に注意を払うのは興味深いことです。PICでは、グローバルデータはGOTを通過する必要があることを思い出してください。以下にアクセスするコードを示しますglobal_arr。

  t += global_arr[7];
36:   48 8b 05 00 00 00 00    mov    0x0(%rip),%rax
3d:   8b 40 1c                mov    0x1c(%rax),%eax
40:   01 45 fc                add    %eax,-0x4(%rbp)

対象となる再配置はR_X86_64_GOTPCREL、GOT内のシンボルの入力の位置に項を加えたものから、再配置を適用するためのシフトを差し引いたものです。つまり、RIP（次の命令）とglobal_arrGOTで予約されているスロットの間の相対的なシフトがコマンドにパッチされます。したがって、実際のアドレスはraxコマンドの0x36addressに配置されますglobal_arr。このステップの後に、アドレスへの参照のリセットと、のglobal_arr7番目の要素へのオフセットが続きeaxます。

次に、関数呼び出しを見てみましょう。

  int t = global_func(argc);
24:   8b 45 ec                mov    -0x14(%rbp),%eax
27:   89 c7                   mov    %eax,%edi
29:   b8 00 00 00 00          mov    $0x0,%eax
2e:   e8 00 00 00 00          callq  33 <main+0x1e>
33:   89 45 fc                mov    %eax,-0x4(%rbp)

シンボルのオペランドcallqアドレス0x2e、R_X86_64_PLT32：PLTエントリアドレスの再配置と、再配置の適用のための項の負のシフト。つまり、callqのPLTスプリングボードを正しく呼び出す必要がありglobal_funcます。

コンパイラが暗黙的に想定していることに注意してください。GOTとPLTはRIP相対アドレス指定を介してアクセスできるということです。これは、このモデルを他のPICコードモデルバリアントと比較するときに重要になります。

大規模なPICコードモデル

分解：

int main(int argc, const char* argv[])
{
  15: 55                      push   %rbp
  16: 48 89 e5                mov    %rsp,%rbp
  19: 53                      push   %rbx
  1a: 48 83 ec 28             sub    $0x28,%rsp
  1e: 48 8d 1d f9 ff ff ff    lea    -0x7(%rip),%rbx
  25: 49 bb 00 00 00 00 00    movabs $0x0,%r11
  2c: 00 00 00
  2f: 4c 01 db                add    %r11,%rbx
  32: 89 7d dc                mov    %edi,-0x24(%rbp)
  35: 48 89 75 d0             mov    %rsi,-0x30(%rbp)
    int t = global_func(argc);
  39: 8b 45 dc                mov    -0x24(%rbp),%eax
  3c: 89 c7                   mov    %eax,%edi
  3e: b8 00 00 00 00          mov    $0x0,%eax
  43: 48 ba 00 00 00 00 00    movabs $0x0,%rdx
  4a: 00 00 00
  4d: 48 01 da                add    %rbx,%rdx
  50: ff d2                   callq  *%rdx
  52: 89 45 ec                mov    %eax,-0x14(%rbp)
    t += global_arr[7];
  55: 48 b8 00 00 00 00 00    movabs $0x0,%rax
  5c: 00 00 00
  5f: 48 8b 04 03             mov    (%rbx,%rax,1),%rax
  63: 8b 40 1c                mov    0x1c(%rax),%eax
  66: 01 45 ec                add    %eax,-0x14(%rbp)
    t += static_arr[7];
  69: 48 b8 00 00 00 00 00    movabs $0x0,%rax
  70: 00 00 00
  73: 8b 44 03 1c             mov    0x1c(%rbx,%rax,1),%eax
  77: 01 45 ec                add    %eax,-0x14(%rbp)
    t += global_arr_big[7];
  7a: 48 b8 00 00 00 00 00    movabs $0x0,%rax
  81: 00 00 00
  84: 48 8b 04 03             mov    (%rbx,%rax,1),%rax
  88: 8b 40 1c                mov    0x1c(%rax),%eax
  8b: 01 45 ec                add    %eax,-0x14(%rbp)
    t += static_arr_big[7];
  8e: 48 b8 00 00 00 00 00    movabs $0x0,%rax
  95: 00 00 00
  98: 8b 44 03 1c             mov    0x1c(%rbx,%rax,1),%eax
  9c: 01 45 ec                add    %eax,-0x14(%rbp)
    return t;
  9f: 8b 45 ec                mov    -0x14(%rbp),%eax
}
  a2: 48 83 c4 28             add    $0x28,%rsp
  a6: 5b                      pop    %rbx
  a7: c9                      leaveq
  a8: c3                      retq

再配置：今回は、大きなデータと小さなデータの違いはまだ問題ではないので、とに焦点を当てます。しかし、最初にこのコードのプロローグに注意を払う必要があります。以前はこれに遭遇していませんでした。

Relocation section '.rela.text' at offset 0x62c70 contains 6 entries:
      

        
        
        
      

    
 Offset Info Type Sym. Value Sym. Name + Addend
      

        
        
        
      

    
000000000027 00150000001d R_X86_64_GOTPC64 0000000000000000 _GLOBAL_OFFSET_TABLE_ + 9
      

        
        
        
      

    
000000000045 00160000001f R_X86_64_PLTOFF64 0000000000000000 global_func + 0
      

        
        
        
      

    
000000000057 00110000001b R_X86_64_GOT64 0000000000000000 global_arr + 0
      

        
        
        
      

    
00000000006b 000800000019 R_X86_64_GOTOFF64 00000000000001a0 static_arr + 0
      

        
        
        
      

    
00000000007c 00120000001b R_X86_64_GOT64 0000000000000340 global_arr_big + 0
      

        
        
        
      

    
000000000090 000900000019 R_X86_64_GOTOFF64 0000000000031080 static_arr_big + 0

static_arrglobal_arr

1e: 48 8d 1d f9 ff ff ff    lea    -0x7(%rip),%rbx
25: 49 bb 00 00 00 00 00    movabs $0x0,%r11
2c: 00 00 00
2f: 4c 01 db                add    %r11,%rbx

以下に、ABIからの関連する引用の翻訳を示します。

( GOT) AMD64 IP- . GOT . GOT , AMD64 ISA 32 .

上記のプロローグがGOTアドレスを計算する方法を見てみましょう。最初に、アドレスのコマンド0x1eが自身のアドレスをにロードしますrbx。次に、再配置とともにR_X86_64_GOTPC64、絶対64ビットステップが実行されr11ます。この再配置は、次のことを意味します。GOTアドレスを取得し、シフトされたシフトを減算して、項を追加します。最後に、住所のチーム0x2fが両方の結果を合計します。結果はGOTの絶対アドレスrbxです。 [7]

なぜGOTアドレスを計算する必要があるのですか？まず、引用で述べたように、大規模なコードモデルでは、32ビットのRIP相対シフトでGOTアドレッシングが十分であると想定できないため、完全な64ビットアドレスが必要です。次に、PICバリエーションを引き続き使用するため、単純に絶対アドレスをレジスターに入れることはできません。むしろ、アドレス自体はRIPに対して相対的に計算する必要があります。それがプロローグの目的です。64ビットのRIP相対計算を実行します。

とにかく、rbxGOTアドレスを取得したので、アクセス方法を見てみましょうstatic_arr。

  t += static_arr[7];
69:       48 b8 00 00 00 00 00    movabs $0x0,%rax
70:       00 00 00
73:       8b 44 03 1c             mov    0x1c(%rbx,%rax,1),%eax
77:       01 45 ec                add    %eax,-0x14(%rbp)

最初のコマンドの再配置は、R_X86_64_GOTOFF64シンボルとマイナスGOT項です。この場合、これはアドレスstatic_arrとGOTアドレス間の相対オフセットです。次の命令は、結果をrbx（絶対GOTアドレス）に追加し、参照によってオフセットをリセットします0x1c。このような計算を簡単に視覚化するために、疑似Cの例を以下に示します。

// char* static_arr
// char* GOT
rax = static_arr + 0 - GOT;  // rax now contains an offset
eax = *(rbx + rax + 0x1c);   // rbx == GOT, so eax now contains
                             // *(GOT + static_arr - GOT + 0x1c) or
                             // *(static_arr + 0x1c)

興味深い点に注意してください。GOTアドレスはへのバインディングとして使用されstatic_arrます。通常、GOTにはシンボルのアドレスが含まれていません。また、GOTはstatic_arr外部シンボルではないため、GOT内に格納する必要はありません。ただし、この場合、GOTはデータセクションの相対シンボルアドレスへのバインディングとして使用されます。このアドレスは、特に場所に依存しないため、完全な64ビットシフトで見つけることができます。リンカはこの再配置を処理できるため、起動時にコードセクションを変更する必要はありません。

しかし、どうglobal_arrですか？

  t += global_arr[7];
55:       48 b8 00 00 00 00 00    movabs $0x0,%rax
5c:       00 00 00
5f:       48 8b 04 03             mov    (%rbx,%rax,1),%rax
63:       8b 40 1c                mov    0x1c(%rax),%eax
66:       01 45 ec                add    %eax,-0x14(%rbp)

このコードは少し長く、再配置は通常のものとは異なります。実際には、GOTは、より伝統的な方法で使用されている：移転R_X86_64_GOT64のためmovabsだけではGOTのシフト配置する機能告げるraxアドレスが配置されているがglobal_arr。アドレスのコマンドは、GOTから0x5fアドレスglobal_arrを取得し、それをに配置しraxます。次のコマンドは、への参照をリセットし、値をglobal_arr[7]に入れますeax。

では、のコードリンクを見てみましょうglobal_func。大規模なコードモデルでは、コードセクションのサイズについて想定できないため、PLTにアクセスする場合でも、絶対64ビットアドレスが必要であると想定する必要があります。

  int t = global_func(argc);
39: 8b 45 dc                mov    -0x24(%rbp),%eax
3c: 89 c7                   mov    %eax,%edi
3e: b8 00 00 00 00          mov    $0x0,%eax
43: 48 ba 00 00 00 00 00    movabs $0x0,%rdx
4a: 00 00 00
4d: 48 01 da                add    %rbx,%rdx
50: ff d2                   callq  *%rdx
52: 89 45 ec                mov    %eax,-0x14(%rbp)

対象となる再配置はR_X86_64_PLTOFF64、PLT入力global_funcアドレスからGOTアドレスを引いたものです。結果はに配置されrdx、そこで配置されますrbx（GOTの絶対アドレス）。その結果、我々はのためのPLTエントリのアドレスを取得します。ここでもGOTがアンカーとして使用されていることに注意してください。今回は、PLT入力のオフセットへのアドレスに依存しない参照を提供します。global_funcrdx

平均PICコードモデル

最後に、平均的なPICモデルの生成コードを分解します。

int main(int argc, const char* argv[])
{
  15:   55                      push   %rbp
  16:   48 89 e5                mov    %rsp,%rbp
  19:   53                      push   %rbx
  1a:   48 83 ec 28             sub    $0x28,%rsp
  1e:   48 8d 1d 00 00 00 00    lea    0x0(%rip),%rbx
  25:   89 7d dc                mov    %edi,-0x24(%rbp)
  28:   48 89 75 d0             mov    %rsi,-0x30(%rbp)
    int t = global_func(argc);
  2c:   8b 45 dc                mov    -0x24(%rbp),%eax
  2f:   89 c7                   mov    %eax,%edi
  31:   b8 00 00 00 00          mov    $0x0,%eax
  36:   e8 00 00 00 00          callq  3b <main+0x26>
  3b:   89 45 ec                mov    %eax,-0x14(%rbp)
    t += global_arr[7];
  3e:   48 8b 05 00 00 00 00    mov    0x0(%rip),%rax
  45:   8b 40 1c                mov    0x1c(%rax),%eax
  48:   01 45 ec                add    %eax,-0x14(%rbp)
    t += static_arr[7];
  4b:   8b 05 00 00 00 00       mov    0x0(%rip),%eax
  51:   01 45 ec                add    %eax,-0x14(%rbp)
    t += global_arr_big[7];
  54:   48 8b 05 00 00 00 00    mov    0x0(%rip),%rax
  5b:   8b 40 1c                mov    0x1c(%rax),%eax
  5e:   01 45 ec                add    %eax,-0x14(%rbp)
    t += static_arr_big[7];
  61:   48 b8 00 00 00 00 00    movabs $0x0,%rax
  68:   00 00 00
  6b:   8b 44 03 1c             mov    0x1c(%rbx,%rax,1),%eax
  6f:   01 45 ec                add    %eax,-0x14(%rbp)
    return t;
  72:   8b 45 ec                mov    -0x14(%rbp),%eax
}
  75:   48 83 c4 28             add    $0x28,%rsp
  79:   5b                      pop    %rbx
  7a:   c9                      leaveq
  7b:   c3                      retq

移転：

Relocation section '.rela.text' at offset 0x62d60 contains 6 entries:
  Offset          Info           Type           Sym. Value    Sym. Name + Addend
000000000021  00160000001a R_X86_64_GOTPC32  0000000000000000 _GLOBAL_OFFSET_TABLE_ - 4
000000000037  001700000004 R_X86_64_PLT32    0000000000000000 global_func - 4
000000000041  001200000009 R_X86_64_GOTPCREL 0000000000000000 global_arr - 4
00000000004d  000300000002 R_X86_64_PC32     0000000000000000 .data + 1b8
000000000057  001300000009 R_X86_64_GOTPCREL 0000000000000000 global_arr_big - 4
000000000063  000a00000019 R_X86_64_GOTOFF64 0000000000030d40 static_arr_big + 0

まず、関数呼び出しを削除しましょう。小規模モデルと同様に、中間モデルでは、コード参照が32ビットRIPシフトの制限を超えないことを前提としているため、呼び出しのglobal_funcコードは、小規模PICモデルの同じコード、static_arrおよび小規模データ配列とに完全に類似していますglobal_arr。したがって、ここではビッグデータ配列に焦点を当てますが、最初にプロローグについて話しましょう。ここでは、大きなデータモデルのプロローグとは異なります。

1e:   48 8d 1d 00 00 00 00    lea    0x0(%rip),%rbx

これは全体のプロローグです。再配置を使用しR_X86_64_GOTPC32てGOTアドレスをに配置するために必要なrbxチームは1つだけです（大規模モデルでは3つ）。違いはなんですか？真ん中のモデルではGOTが「ビッグデータセクション」の一部ではないため、32ビットシフト内で使用できると想定しています。大規模なモデルでは、このような仮定を行うことができず、完全な64ビットシフトを使用せざるを得ませんでした。

興味深いのは、アクセスするためのglobal_arr_bigコードが小さなPICモデルの同じコードに似ていることです。これは、ミドルモデルのプロローグがラージモデルのプロローグよりも短いのと同じ理由で、GOTは32ビットRIP相対アドレッシング内で使用できると想定しています。確かに、非常にglobal_arr_bigそのようなアクセスはできませんが、実際global_arr_bigにはGOT 内に完全な64ビットアドレスの形式で配置されているため、このケースはGOTをカバーしています。

ただし、状況は次のように異なりstatic_arr_bigます。

  t += static_arr_big[7];
61:   48 b8 00 00 00 00 00    movabs $0x0,%rax
68:   00 00 00
6b:   8b 44 03 1c             mov    0x1c(%rbx,%rax,1),%eax
6f:   01 45 ec                add    %eax,-0x14(%rbp)

このケースは大規模なPICコードモデルに似ています。ここでは、GOT自体にはないシンボルの絶対アドレスを取得しているからです。これは大きなシンボルであり、下位2ギガバイトにあるとは想定できないため、大きなモデルと同様に、64ビットのPICシフトが必要です。

ノート：

[1]コードモデルと64ビットデータモデルおよびIntelメモリモデルを混同しないでください。これらはすべて異なるトピックです。

[2]覚えておくことが重要です。実際のコマンドはコンパイラによって作成され、アドレッシングモードはこのステップで正確に修正されます。コンパイラは、オブジェクトモジュールがどのプログラムまたは共有ライブラリに分類されるかを認識できません。小さいものと大きいものがあります。リンカは最終的なプログラムのサイズを知っていますが、手遅れです。リンカはコマンドのシフトに再配置でのみパッチを当てることができ、コマンド自体を変更することはできません。したがって、コードモデルの「規約」は、コンパイル時にプログラマーが「署名」する必要があります。

[3]不明な点がある場合は、次の記事をご覧ください。

[4]ただし、ボリュームは徐々に増加しています。前回、Debug + AssertsのClangビルドを確認したところ、ほぼ1ギガバイトに達しました。これは、自動生成されたコードのおかげです。

[5] PICの動作がまだわからない場合（一般に、特にx64アーキテクチャーの両方で）、このトピックに関する次の記事を理解してください：1回と2回。

[6]したがって、リンカはリンクを個別に解決することができず、GOT処理をダイナミックローダーにシフトする必要があります。

[7] 0x25-0x7 + GOT-0x27 + 0x9 = GOT

x64アーキテクチャコードモデルについて