動的リンクと共有ライブラリの仕組み

なぜlibcは増えないのか

数百のプロセスが同じ libc.so.6 を使っていても、物理メモリ上に libc のコードは基本的に一つしか存在しません。この「共有」をどう実現し、プロセスごとに違う部分をどう分離しているか、検索パスの優先順位がなぜあの順なのか。動的リンクの内部はこの三点に集約できます。本稿はロードと再配置の流れ（ELFバイナリのロードとリンカ・ローダの内部 で解説）を前提に、その先の共有・PIC・バージョニング・検索順序を掘り下げます。

共有ライブラリの物理ページ共有

共有ライブラリ（.so）は ld.so が mmap でプロセスのアドレス空間に貼り付けます。重要なのは、コードセグメント（r-x）が読み取り専用かつファイルバックドなマッピングである点です。同じファイルを複数プロセスがマップすると、カーネルはページキャッシュ上の同一物理ページを各プロセスのページテーブルから参照させます。コードは書き換わらないので、何プロセスが起動しても物理ページは一つで済みます（メモリマップトファイル（mmap） の共有マッピングと同じ原理）。

問題は書き込みが生じる領域です。共有ライブラリにも初期値付きデータ（.data）や GOT（解決結果を書き込む表）があり、ここはプロセスごとに値が違わねばなりません。そこでデータセグメントは MAP_PRIVATE で貼られ、書き込みが起きたページだけコピーオンライト（CoW） で複製されます。

つまり「共有されるのは不変なコードと読み取り専用データ、プロセス固有になるのは書き換えるデータ」という線引きです。この分離が成り立つには、コード自体がプロセスごとに違う番地で動いても書き換え不要であること、すなわち位置独立であることが前提になります。

位置独立コード（PIC）の必要性

共有ライブラリはどの番地にロードされるか事前に決まりません。ASLR でロードごとに動きますし、複数の .so が衝突しない番地に並べる都合もあります。もしコードが絶対番地を直書きしていたら、ロード番地に応じて命令そのものを書き換える（テキスト再配置）必要が生じ、コードページがプロセスごとに変わって共有できなくなります。これを避けるのが PIC（Position Independent Code） です。

PIC は外部・グローバルなシンボル参照を、絶対番地ではなく次の二段で表現します。

• コード内参照は RIP 相対: 現在の命令位置からの相対オフセットでアクセスする。ロード番地が変わっても相対距離は不変なので、命令を書き換えずに済む。
• グローバルデータ／外部関数は GOT 経由: 番地が確定しない参照は GOT（Global Offset Table）という表を間接参照する。命令には「GOT の何番目」という固定オフセットだけを書き、実番地は ld.so が GOT に書き込む。

; 非PIC（絶対番地直書き）— ロード番地ごとに命令の書き換えが要る
mov rax, [0x404050]        ; global_var の絶対アドレス

; PIC（GOT間接）— 命令は固定、GOTの中身だけ実番地で埋める
mov rax, [rip + global_var@GOTPCREL]  ; GOTエントリをRIP相対で引く
mov rax, [rax]                         ; GOT経由で実体へ

ポイントは「書き換えるのはデータ（GOT）だけで、コードは不変」という構造です。GOT は書き込み可能データなのでプロセスごとに違う値を持てますが、コードページは全プロセスで共有したまま再配置を吸収できます。PIC のわずかな間接参照コストと引き換えに、コード共有という大きな利得が得られます。

シンボルのバージョニングと相互参照

共有ライブラリの存在意義は ABI 互換、つまりライブラリを差し替えても再コンパイルなしに既存バイナリが動くことです。しかし関数の挙動を変えたい場面では、古い呼び出し元を壊さずに新しい定義を提供したくなります。これを可能にするのがシンボルバージョニングです。

仕組みは、同名のシンボルに版（version node, 例 GLIBC_2.2.5, GLIBC_2.34）を付け、同じ名前で複数世代を一つの .so に共存させるものです。

• ライブラリ側は version script で各シンボルに版を割り当て、さらに**既定版（default version）**を一つ指定する。
• バイナリ側は、リンク時に見えていた版を参照として埋め込む（memcpy@GLIBC_2.2.5 のように @ で版を固定）。
• 古いバイナリは古い版のシンボルへ、新しくリンクしたバイナリは新しい既定版へ結びつく。両方の実体が同じ .so に入っているので、一つのライブラリで新旧を同時に満たせる。

相互参照（あるライブラリ内のシンボルを別のオブジェクトが参照する）の解決は、グローバルスコープの探索順に従います。ld.so は読み込んだオブジェクトをロード順（幅優先）に並べたグローバルスコープを持ち、シンボルを探すとき**最初に見つかった定義を採用（先勝ち）**します。実行ファイル本体は通常スコープ先頭に来るため、本体が定義したシンボルが共有ライブラリ内の同名定義より優先されます。この「先勝ち」が、次節の LD_PRELOAD による差し替えを成立させる土台です。

preload/RPATH/RUNPATHの解決順序

ld.so が依存ライブラリ（DT_NEEDED に列挙された .so）を探すとき、検索ディレクトリには明確な優先順位があります。さらに、どのシンボル定義を採用するかというスコープ順と、どのディレクトリを見るかというパス順は別の話なので分けて理解します。

まずファイルを探すディレクトリの順序です。

DT_RPATH と DT_RUNPATH は紛らわしいので内部差を押さえます。両者ともバイナリに埋め込むライブラリ検索パスですが、探索範囲と優先順位が異なります。

検索順序とは別に、シンボル解決のスコープ順で LD_PRELOAD は強力です。preload された .so はグローバルスコープのほぼ先頭に挿入されるため、先勝ち規則によって libc の malloc などと同名の関数を横取りできます。デバッガやプロファイラ、メモリチェッカが関数を差し替えられるのはこの仕組みです。逆に言えば、preload は任意コードを既存プロセスに割り込ませる経路でもあるため、setuid バイナリでは LD_PRELOAD と LD_LIBRARY_PATH は無視されます（昇格権限の奪取を防ぐため）。

つまずきポイント

• 「共有ライブラリ＝メモリ完全共有」ではない。共有されるのは読み取り専用のコードと .rodata だけです。.data と GOT はプロセス固有で、書き込み時に CoW でページが分かれます。
• PIC と PIE を混同しない。PIC は共有ライブラリのコード共有を支える性質、PIE は実行ファイル本体を任意配置にして ASLR を効かせる性質です。.so は常に PIC ですが、本体は PIE にしない限り位置依存です。
• バージョニングは名前マングリングではない。C++ のマングリングが型情報を名前に埋めるのに対し、シンボルバージョニングは ABI 世代を @version で区別する別機構です。同名関数の挙動変更を、再コンパイルなしに新旧両立させるためのものです。
• RUNPATH は孫依存に効かない。$ORIGIN 相対の DT_RUNPATH を埋め込んでも、それは直接依存にしか適用されません。依存の依存まで自前パスで解決させたいなら各オブジェクトに RUNPATH を持たせる必要があります。

まとめ

• 共有ライブラリのコードと読み取り専用データはファイルバックド共有マッピングで複数プロセスが同一物理ページを共有し、書き換わる .data と GOT だけが MAP_PRIVATE で CoW によりプロセス固有化される。
• PIC は RIP 相対参照と GOT 間接参照により、命令を書き換えずに任意番地で動くコードを実現し、これがコードページ共有の前提になる。.so は常に PIC でビルドされる。
• シンボルバージョニングは @version で同名シンボルの複数 ABI 世代を一つの .so に共存させ、再コンパイルなしの新旧両立を可能にする。相互参照はグローバルスコープの先勝ちで解決される。
• 検索順序は LD_PRELOAD → DT_RPATH（DT_RUNPATH 不在時）→ LD_LIBRARY_PATH → DT_RUNPATH → ld.so.cache → 既定ディレクトリ。RUNPATH は RPATH より後に効き直接依存のみに適用され、RUNPATH があれば RPATH は無視される。

ロードと再配置の前段は ELFバイナリのロードとリンカ・ローダの内部、配置のランダム化と空間レイアウトは プロセスアドレス空間のレイアウトとASLR、実体ページがいつ割り当てられるかは デマンドページングとページフォルト処理 と合わせて読むと、ロード・共有・解決の全体像が一本につながります。