こんにちは！日々の開発、本当にお疲れ様です。
今日は、多くのエンジニアが「ブラックボックス」として恐れ、そして魅了される領域――JIT（Just-In-Time）コンパイル環境のデバッグについてお話しします。
「プログラムが実行中に自分で機械語をメモリ上に書き出し、それをジャンプして実行する……そんな魔法のようなコード、どうやってデバッグすればいいんだ？」
そう思ったことはありませんか？
V8（JavaScriptエンジン）やJVM、あるいは自作の簡易言語処理系などを作っていると、動的に生成されたコードのバグに直面します。通常のデバッガ（LLDBやGDB）は、ソースコードと静的なバイナリファイル（ELFやMach-O）の対応関係（DWARFなどのデバッグ情報）を前提としているため、メモリ上で忽然と生まれるコードの前では途方に暮れてしまいます。
ですが、安心してください。「デバッガを少しだけ騙して、動的コードを人間が読めるアセンブリとして認識させる裏技」をマスターすれば、JITコードの内部も、まるで普通のC言語関数をステップ実行するかのように手に取るように追跡できるようになります。
今回は、LLDBを使ってメモリ上に動的生成されたコードをステップ実行する技術の本質を、優しく、そして徹底的に紐解いていきましょう。これをマスターすれば、低レイヤの動作原理に対する恐怖が消え去り、あなたのエンジニアとしての視野は劇的に広がりますよ！
—
1. なぜJITコードのデバッグはこれほどまでに難しいのか？
私たちが普段使っているデバッガ（LLDBやGDB）は、コンパイル時に出力された「デバッグ情報（シンボルテーブル）」を頼りに動いています。
「このメモリアドレス `0x100003f40` は、`main.c` の 15行目にあたる」といった地図（対応表）があらかじめ用意されているからこそ、ブレークポイントを貼ったり、変数の名前を表示したりできるわけです。
しかし、JITコンパイラは違います。
1. プログラムが実行中に、
2. ヒープや専用のメモリ領域に機械語（バイトコードの塊）を動的に書き込み、
3. そのメモリ領域に対して「ここを実行せよ（関数ポインタとして呼び出す）」とCPUに指示します。
この時、OSのメモリ領域には「名前のないただのバイナリ」しか存在しません。デバッガから見れば、それは単なる「数字の羅列」であり、ソースコードの影も形もないのです。ここにブレークポイントを貼ろうとしても、「そんなアドレスにシンボルはない」と怒られてしまいます。
—
2. 開発環境の準備：JITを模した「動的コード生成」の実験台
まずは、この難局を体験し、克服するための実験台を作りましょう。
今回は、現代のmacOSやLinuxで標準的に使われる LLDB を用います。
JITコンパイラのミニチュアとして、「メモリ上に機械語の足し算命令を書き込み、それを関数として実行するプログラム」をC言語で記述します。
以下のコードを手元の環境（macOSまたはLinux）で `jit_sample.c` として保存してください。
include
include
include
include
// 実行する機械語（x86_64アーキテクチャの場合）
// 処理内容: 引数 (rdi) に 10 を足して返す関数
// アセンブリ:
// add rdi, 10
// ret
// 機械語バイト列:
// 48 83 c7 0a (add rdi, 10)
// c3 (ret)
unsigned char code_template[] = {
0x48, 0x83, 0xc7, 0x0a, // add rdi, 10
0xc3 // ret
};
// 関数ポインタの型定義
typedef long (jit_func_t)(long);
int main() {
// 1. 実行権限（PROT_EXEC）を持ったメモリ領域を動的に確保する
// ※モダンなOSでは、ヒープやスタックに直接実行権限を持つことはセキュリティ上禁止されているため mmap を使う
void mem = mmap(NULL, 4096, PROT_READ | PROT_WRITE | PROT_EXEC,
MAP_ANON | MAP_PRIVATE, -1, 0);
if (mem == MAP_FAILED) {
perror(“mmap failed”);
return 1;
}
// 2. テンプレートの機械語を確保したメモリ領域にコピーする（JITコンパイラのコード生成を模倣）
memcpy(mem, code_template, sizeof(code_template));
// 3. 確保したメモリ領域を関数ポインタとしてキャスト
jit_func_t my_jit_func = (jit_func_t)mem;
printf(“JITコードのメモリ上のアドレス: %p\n”, (void)my_jit_func);
printf(“ブレークポイントを貼る準備をしてください…\n”);
// デバッガでアタッチする時間を作るためのスリープ（無限ループ）
volatile int wait_for_debugger = 1;
while (wait_for_debugger) {
// デバッガから `set wait_for_debugger = 0` と書き換えることで先に進める
}
// 4. 動的生成されたコードを実行！
long result = my_jit_func(5); // 5 + 10 = 15 になるはず
printf(“実行結果: %ld\n”, result);
// 5. メモリの解放
munmap(mem, 4096);
return 0;
}
コンパイル方法
最適化を切って（`-O0`）、デバッグ情報（`-g`）を付与してコンパイルします。
macOS (Clang) の場合
clang -g -O0 jit_sample.c -o jit_sample
Linux (GCC) の場合
gcc -g -O0 jit_sample.c -o jit_sample
—
3. 基礎セットアップ：LLDBでプロセスを捉える
プログラムを実行すると、先ほど記述した `JITコードのメモリ上のアドレス: 0x107800000` のようなアドレスが表示され、無限ループで待機状態に入ります。
ここからが本番です。別のターミナルを開き、動いているプロセスに LLDB でアタッチしましょう。
プロセスIDを指定してLLDBを起動
lldb -p $(pgrep jit_sample)
LLDBが起動したら、まずは無限ループを抜け出すために、C言語側の変数を書き換えます。
(lldb) expr wait_for_debugger = 0
(lldb) continue
これでプログラムが動き出しますが、JIT関数が呼ばれる前に止めたいですね。一度 `Ctrl + C` でプロセスを一時停止（ポーズ）させます。
—
4. 現場で震えるほど役立つ裏技：動的メモリにシンボルを「偽装」する
さて、ここからが今回のハイライトです。
JITコードが存在するアドレス（例：`0x107800000`）が分かっていますが、このままだと `disassemble -a 0x107800000` と打っても、LLDBはうまく逆アセンブルしてくれないか、シンボル名が解決できません。
ここで、「LLDBのシンボルテーブルを手動で拡張する」という裏技を使います。
ステップ1: メモリ上のバイナリを逆アセンブルして確認する
まずは、動的に生成されたメモリ領域を直接覗いてみましょう。
(lldb) disassemble -s 0x107800000 -c 2
(※ `0x107800000` の部分は、ご自身の環境で出力されたアドレスに置き換えてください)
実行結果に、以下のようなアセンブリが表示されるはずです。
0x107800000: 48 83 c7 0a addq $0xa, %rdi
0x107800004: c3 retq
見事に、私たちが書き込んだ機械語がメモリ上に存在しています！
ステップ2: カスタムシンボル（名前）を付与する
JITエンジンの開発において、生成したコードごとに名前（例: `jit_function_add_10`）をデバッガに認識させられたらどれほど楽か。実は、LLDBのスクリプトインターフェース（Python）や低レイヤコマンドを使うことで、カスタムシンボルを注入できます。
もっとも手軽で強力な方法は、「ブレークポイントに名前（シンボル的役割）を付与し、逆アセンブルの目印にすること」です。
(lldb) breakpoint set –address 0x107800000 –name “my_dynamically_generated_func”
これによって、LLDBはこのアドレスをただの数字ではなく、`my_dynamically_generated_func` という意味を持った関数として認識し始めます。
—
5. 動的コードのステップ実行を体感する
それでは、このJIT関数が呼び出される瞬間を捉えてみましょう。
先ほど設定したブレークポイントまで実行を進めます。
(lldb) continue
プログラムがJIT関数の先頭（`0x107800000`）でヒットして止まります！
ここからが感動の瞬間です。通常の関数と同様に、ステップオーバー（`si` / ステップ・インストラクション）を使って、機械語レベルで処理を追跡できます。
(lldb) si
CPUのレジスタの状態を確認してみましょう。
(lldb) register read
出力結果を見ると、引数として渡された `rdi` レジスタの値が `0x5`（10進数で5）になっていることが確認できます。
もう一度 `si` を実行すると、`addq` 命令が実行され、`rdi` の値が `0xf`（15）に変化します。
さらに、スタックフレームや逆アセンブルの現在地を確認したいときは、次のように打ちます。
(lldb) disassemble –pc
動的に生成されたコードであるにもかかわらず、まるでソースコードがあるかのように、CPUの挙動を1命令ずつコントロールできる――。この感覚を掴むと、JITコンパイルや仮想マシンの開発におけるデバッグの絶望感が、一気に「知的な冒険」へと変わります。
—
先輩エンジニアからのエール
お疲れ様でした！
今回はJITコンパイル環境の裏側を覗き、LLDBを使って動的生成コードを華麗にステップ実行する手法を解説しました。
「メモリ上のバイト列に過ぎないものに、どうやって意味を持たせるか」
このアプローチを理解していれば、今後、WebAssemblyのランタイム開発、独自のDSL（ドメイン特化言語）のJIT化、あるいはリバースエンジニアリングやセキュリティ解析の現場に出くわしたときでも、決して怯むことはありません。
「機械語を制する者は、実行時環境を制す」です。
これをマスターしたあなたなら、どんなに複雑な動的システムであっても、内部で何が起きているのかを完全に見通すことができるはずです。
毎日のコーディングと低レイヤの探求を、これからもぜひ楽しんでいきましょう！