ABI・呼び出し規約とリンカの仕組み

ABIと呼び出し規約は何を約束するのか

ソースコードが機械語へ翻訳されても、それだけでは実行できません。複数のオブジェクトファイルやライブラリを1つの実行像に組み上げ、関数同士が正しく値を受け渡せるよう取り決めを揃える必要があります。この取り決めの総体が ABI（Application Binary Interface）です。ABIはバイナリ同士の契約であり、int が何バイトか、構造体のメンバをどう詰めるか、関数をどう呼ぶか、までを規定します。ソースレベルの API（関数の名前や型）に対する、機械語レベルの対応物だと考えてください。翻訳全般の流れはコンパイルとインタプリタで扱っています。

ABIの中核が 呼び出し規約（calling convention）です。これは関数呼び出しに関する次の取り決めを指します。

• 引数を どこに置くか（レジスタかスタックか、その順序）
• 戻り値を どこで返すか
• 誰がスタックを片付けるか（呼び出し側か被呼び出し側か）
• 呼び出しをまたいで どのレジスタを保存すべきか

レジスタ渡しとスタック渡し

現代の64ビットABIは、速度のため引数の先頭いくつかをレジスタで渡します。System V AMD64 ABI（Linux／macOS）では、整数・ポインタ型の引数を rdi, rsi, rdx, rcx, r8, r9 の順に割り当て、7個目以降をスタックへ積みます。浮動小数点は別系統で xmm0〜xmm7 を使います。

long f(long a, long b, long c) { return a + b + c; }
の呼び出し（System V AMD64）:
  a -> rdi,  b -> rsi,  c -> rdx
  戻り値    -> rax

呼び出し規約はレジスタを2種に分けます。呼び出し側保存（caller-saved／volatile、例 rax,rcx,rdx,rsi,rdi,r8-r11）は被呼び出し側が自由に壊してよく、値を残したい呼び出し側が事前退避します。被呼び出し側保存（callee-saved／non-volatile、例 rbx,rbp,r12-r15）は使うなら被呼び出し側が復元責任を負います。この線引きがあるからこそ、別々にコンパイルされた関数が互いの内部を知らずに安全に呼び合えます。引数受け渡しの言語側の見え方は関数も参照してください。

スタックには引数のほか、戻り番地・退避レジスタ・ローカル変数がフレーム単位で積まれます。System V AMD64は call 直前にスタックを16バイト境界へ整える規律も課します（SIMD命令のアライメント要件のため）。スタックとアドレスの関係はポインタと参照、フレームのメモリ配置はメモリレイアウトとデータ局所性で補強できます。

名前修飾とextern "C"

リンカが関数を識別する手がかりは シンボル（識別子の文字列）です。ここで言語差が表面化します。C++はオーバーロード（同名で引数違いの関数）を許すため、関数の引数型や所属名前空間をシンボル名へ符号化します。これが 名前修飾（name mangling）です。

C:    int add(int,int)   ->  シンボル "add"
C++:  int add(int,int)   ->  "_Z3addii"  （ii = int,int）
      double add(double) ->  "_Z3addd"   （別シンボルになる）

Cは修飾しないため、同名関数は1つしか持てません。C++コードからCの関数を呼ぶ（あるいはCへ公開する）には extern "C" を付け、コンパイラに「このシンボルは修飾するな」と指示します。これを忘れると、宣言と定義でシンボル名が食い違い「undefined reference」になります。

リンカの二大仕事——シンボル解決と再配置

リンカの役割は2つに集約できます。第一が シンボル解決で、各オブジェクトファイルの未定義シンボル（外部参照）を、どこかの定義シンボルへ結びつけます。第二が 再配置（relocation）です。コンパイル時点では各関数・変数の最終アドレスが未確定なので、コンパイラは「ここはアドレスを後で埋めよ」という再配置エントリを残します。リンカはセクションを連結して各シンボルの最終アドレスを決め、再配置エントリが指す箇所へ確定値を書き込みます。

オブジェクトA: call <printf>  ← 飛び先アドレス未定（再配置エントリ）
       ↓ リンク（解決＋再配置）
実行像:   call 0x401050     ← printfの確定アドレスを書き込み

静的リンクと動的リンク

最終的な結合をいつ行うかで方式が分かれます。静的リンク はビルド時にライブラリの必要部分を実行ファイルへ取り込みます。実行時依存がなく単体で動く反面、同じライブラリが各プロセスに複製され、更新時は再リンクが要ります。動的リンク は共有ライブラリ（.so／.dll／.dylib）への参照だけを残し、実行時にローダ（動的リンカ）が解決します。

動的リンクの肝が、位置独立コードのための間接参照表です。外部関数は PLT（Procedure Linkage Table）経由で呼ばれ、実アドレスは GOT（Global Offset Table）に格納されます。多くの実装は 遅延束縛 を行い、関数を初めて呼んだ瞬間にだけ解決してGOTへ書き戻します。以後はGOT経由の直接ジャンプで済み、起動コストを最初の呼び出しまで先送りできます。

まとめ

実行ファイル生成の最終段は、ABIという契約の上に成り立ちます。呼び出し規約が引数・戻り値・レジスタ保存責任を定め、別々にコンパイルされた関数が互いの中身を知らずに呼び合えるようにします。名前修飾はオーバーロードを区別するための符号化で、extern "C" がC／C++間の橋渡しになります。リンカはシンボル解決と再配置の2仕事で断片を1つの像に統合し、静的リンクは複製を埋め込み、動的リンクはGOT／PLTと遅延束縛で実行時に解決します。リンクエラーやバージョン不整合は、この「機械語レベルの約束ごと」のどこがずれたかを問う問題です。仕組みを押さえれば、エラーメッセージは原因を指し示す手がかりへと変わります。