動的リンクとシンボル解決（PLT/GOT・遅延束縛）

なぜ動的リンクに間接参照が必要なのか

共有ライブラリ（.so／.dll／.dylib）の狙いは、同じコードを複数のプロセスで物理メモリ上から共有することにあります。libc のコードページを各プロセスが個別に複製していては、メモリも起動コストも無駄になります。共有を成り立たせる条件は、コードページがどのプロセスでも書き換え不要なまま使えることです。ところがプログラムがロードされるアドレスは実行のたびに変わりうる（ASLRもあります）ため、コードの中に絶対アドレスを直接書き込んでしまうと、ロード先ごとにコードを書き換える羽目になり共有が壊れます。

この矛盾を解くのが 位置独立コード（PIC: Position-Independent Code）です。PICはアドレスを命令の中に焼き込まず、すべての外部参照を1か所のテーブルへの 間接参照 に置き換えます。テーブル自体はプロセスごとに書き換えてよい（プライベートな）データ領域に置き、コード本体は不変に保つ。ここで登場するのが GOT と PLT です。実行ファイル生成全体の流れはABI・呼び出し規約とリンカの仕組み、ロード先がばらつく前提となるアドレス空間の話は仮想メモリとページングのプログラミング的含意で補えます。

GOT——データと関数の実アドレスを置く表

GOT（Global Offset Table）は、外部シンボルの最終アドレスを格納する書き換え可能なテーブルです。コードは「GOTのこのスロットを読んで、そこに書いてあるアドレスへ行け」という間接参照だけを持ちます。スロットの中身（実アドレス）はロード時または初回呼び出し時に確定して書き込まれるので、コード本体は一切書き換わりません。

GOTは用途で性質が分かれます。外部 データ オブジェクト（グローバル変数など）への参照は、ロード直後に動的リンカが一括で埋めます（即時束縛）。一方、外部 関数 への参照は、後述する遅延束縛のために最初は仮の値を指しておき、初回呼び出しで差し替えます。

コード側（不変）:
    mov rax, [rip + global_x@GOTPCREL]  ; GOTスロットを読む
    mov eax, [rax]                       ; その先の実体を読む
GOT側（プロセスごとに書き換え可）:
    [global_x のスロット] = 0x7f...1234  ; ロード時にリンカが書き込む

PLT と遅延束縛——初回だけ解決する仕掛け

すべての外部関数アドレスを起動時に解決すると、実際には呼ばれない関数まで解決して起動が遅くなります。これを避けるのが 遅延束縛（lazy binding）で、その入り口が PLT（Procedure Linkage Table）です。各外部関数には小さなPLTエントリ（数命令の踏み台コード）が割り当てられ、関数呼び出しは直接ではなく対応するPLTエントリへ飛びます。

PLTエントリは「対応するGOTスロットを読んでそこへジャンプ」します。仕掛けの核心は、GOTスロットの初期値がPLTエントリ自身の続き（解決ルーチンへ向かう部分）を指している点です。流れはこうなります。

初回呼び出し:
  call func@plt
    -> PLT[func]: jmp *GOT[func]
       GOT[func] は未解決なので「PLT[0]＋解決ルーチン」へ戻る
    -> 動的リンカ(_dl_runtime_resolve) が func の実アドレスを探索
    -> GOT[func] に実アドレスを書き戻す
    -> func 本体へジャンプ
2回目以降:
  call func@plt
    -> PLT[func]: jmp *GOT[func]
       GOT[func] は実アドレスなので即ジャンプ（解決ルーチンを通らない）

つまり1回目だけ解決の遠回りをし、結果をGOTへキャッシュして以後は直接ジャンプに化けます。これは仮想関数のvtable間接呼び出しと構造が似ていますが、PLT/GOTは リンク時の解決、vtableは 実行時の型による分岐という違いがあります（動的ディスパッチとvtableの内部を参照）。

シンボル解決の順序と干渉（interposition）

ELFの動的シンボル解決は、プロセス内のオブジェクト（実行ファイルと各共有ライブラリ）を一定順序で並べた グローバルなシンボル名前空間 を、先頭から走査して最初に見つかった定義を採用します。この「先頭一致」の性質から、同名シンボルが複数あると、探索順で先に来た方が後続を覆い隠す 現象が起きます。これが シンボル干渉（symbol interposition）です。

干渉は機能でもあり罠でもあります。LD_PRELOAD で自作 malloc を先頭に差し込めば、ライブラリ側の malloc 呼び出しまで横取りできます（プロファイラやメモリデバッガの原理）。一方、意図せず同名シンボルが衝突すると、想定外の定義が呼ばれてデバッグ困難なバグになります。

実務では、ライブラリの公開API以外を __attribute__((visibility("hidden")))（または -fvisibility=hidden）で隠すのが定石です。動的シンボルテーブルが小さくなるため解決が速くなり、内部関数が外部から干渉される事故も防げます。

シンボルバージョニングとABI互換

同じ共有ライブラリを更新しつつ、既存バイナリを再リンクなしで動かし続けたい——これを支えるのが シンボルバージョニング です。各シンボルにバージョンタグ（例 malloc@GLIBC_2.2.5）を付け、古いバイナリは古いバージョンの定義へ、新しいバイナリは新しい定義へ解決させます。1つのライブラリに同名・別バージョンの実体を共存させ、後方互換を保ったままABIを進化できます。

glibc 内に両方が存在:
  realpath@GLIBC_2.2.5   ← 旧挙動（古いバイナリ向け）
  realpath@GLIBC_2.3     ← 新挙動（@@ で既定版を指定）
古いプログラムは古い版へ、新しいプログラムは新しい版へ解決される

これは soname（libfoo.so.2 のメジャー番号）によるファイル単位の互換管理より細かい、シンボル単位 の互換制御です。sonameのメジャーが変わればライブラリ全体が非互換ですが、シンボルバージョニングならファイルは1つのまま個々の関数の互換性を管理できます。コンパイルからロードまでの全体像はコンパイルとインタプリタと合わせて押さえると、どの段で何が確定するかが整理できます。

まとめ

動的リンクは「コードページの共有」という利得を、間接参照 という一手で実現します。PICが絶対アドレスをコードから追い出し、GOTが実アドレスを置く書き換え可能な表、PLTがそのGOTを踏む踏み台となって、初回呼び出し時だけ解決する遅延束縛を成立させます。一方でグローバルな名前空間の先頭一致探索はシンボル干渉を生み、可視性属性・バージョンスクリプト・シンボルバージョニングがそれを制御してABIの公開面と互換性を管理します。遅延束縛は速い起動と引き換えにGOT改ざんのリスクを抱え、RELROがそのトレードオフを調整します。ldd や readelf が吐く情報は、この一連の約束ごとのどこを見ているかを知れば、起動失敗や性能・セキュリティの判断材料へと変わります。