1. はじめに：なぜJIT開発におけるデバッグはこれほどまでに絶望的なのか
独自の言語処理系やJIT（Just-In-Time）コンパイラを自作しているエンジニアなら、一度は次のような絶望感を味わったことがあるはずだ。
Process 12345 stopped
- thread #1, queue = ‘com.apple.main-thread’, stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
frame #0: 0x00007fff71234567
-> 0x00007fff71234567: movq (%rax), %rbx
(lldb) bt
- frame #0: 0x00007fff71234567
frame #1: 0x000000010040123a
frame #2: 0x0000000100400f10
スタックトレースに現れるのは、メモリ上の無機質なアドレス（`0x00007fff…`）のみ。ソースコードの行番号も、自作言語の変数名も影形もない。そこにあるのは、OSから突きつけられた無慈悲なセグメンテーション違反（`EXC_BAD_ACCESS`）という現実だけだ。
LLVMをバックエンドに採用した言語処理系において、コード生成（IRからMachine Codeへの変換）は一瞬で行われる。しかし、その生成された機械語がどのソースコードのどの式に由来するのかをデバッガ（LLDB）に正しく伝達していなければ、デバッグは「暗闇の中で手探りで地雷原を歩く」ようなものだ。
本記事では、LLVMベースのJIT環境において、動的に生成されたコードにDwarfデバッグ情報を付与し、LLDBのJITデバッグ機能を完全に手なずけて「ソースコードレベルでのステップ実行」を実現する高度な解析手法を、テックリードの視点から徹底解説する。
—
2. LLDB JITデバッグの内部メカニズム：なぜセグフォは起き、どうやって追跡するのか
動的コード生成時のメモリとシンボルの乖離
静的コンパイル（AOT）であれば、コンパイラはバイナリ内に`.debug_info`や`.debug_line`といったDWARFセクションを埋め込み、OSのローダーがそれをシンボルとしてメモリ上にマッピングする。
しかしJITの場合、コードは`mmap`（`MAP_ANON`等）によってヒープ領域や専用の実行可能メモリ領域に動的に書き込まれ、CPUに実行権が渡される。LLDBから見れば、この領域は単なる「無名のメモリブロック」であり、対応するソースコードの存在など知る由もない。
解決の鍵：`JITEventListener` と `JITLoader`
LLVMには、JITコンパイルされたコードのライフサイクル（生成、登録、破棄）をデバッガに通知する仕組みが備わっている。
LLVMの `JITEventListener::createGDBRegistrationListener()` を用いると、JITコードが生成された瞬間に、メモリ上の機械語イメージと対応するDWARFデバッグ情報をgdb/lldb互換のインターフェースを通じてデバッガに通知できる。
この仕組みを正しく構築することで、LLDBは動的コードを「あたかも通常の共有ライブラリ（`.dylib` / `.so`）」であるかのように認識し、ブレークポイントの設置や変数のインスペクションが可能になる。
—
3. 実践：JITイメージの生成とLLDBへの教え込み
ここでは、LLVMのAPIを叩いてJITコードを生成し、LLDBがそれを解釈できるように登録するC++のコード片と、LLDB側の設定アプローチを示す。
ステップ1: JITイベントリスナーの登録（言語処理系ランタイム側）
LLVMのORC JIT（On-Request-Compilation JIT）を使用する場合、ExecutionSessionに対してJITEventListenerをアタッチする必要がある。
include “llvm/ExecutionEngine/Orc/LLJIT.h”
include “llvm/ExecutionEngine/JITEventListener.h”
include “llvm/Support/TargetSelect.h”
// JIT環境を初期化し、GDB/LLDB用のイベントリスナーを接続する関数
std::unique_ptr
// ターゲットマシンのネイティブアセンブリ機能を初期化
llvm::InitializeNativeTarget();
llvm::InitializeNativeTargetAsmPrinter();
auto JITBuilder = llvm::orc::LLJITBuilder();
auto JITOrErr = JITBuilder.create();
if (!JITOrErr) {
// エラーハンドリング（実務では適切に例外やExpected処理を行う）
return nullptr;
}
auto JIT = std::move(JITOrErr);
// 【重要】LLVMが生成した機械語とDWARF情報をLLDB/GDBに通知するリスナーを追加
// これにより、LLDBがJIT領域のメモリ変更をフックできるようになる
JIT->getObjLinkingLayer().registerJITEventListener(
llvm::JITEventListener::createGDBRegistrationListener()
);
return JIT;
}
ステップ2: DWARFラインテーブルの動的生成と登録
機械語をメモリに配置するだけでは不十分だ。「この機械語のオフセット `+0x12` は、自作言語のファイル `main.mylang` の 42行目に対応する」という対応表（Line Table）をLLVMの `DIBuilder` を用いて構築し、オブジェクトファイル形式にパッケージングしてJITに渡す必要がある。
—
4. LLDBを極限まで使い倒す：プロフェッショナルの設定とショートカット
JITデバッグを行う際、デフォルトのLLDBのままでは対話セッションのたびに手動でシンボルを読み込ませるなど、認知負荷が高すぎる。ここからは、チーム全体の開発スピードを跳ね上げる実用的な設定を公開する。
1. チーム共有可能なLLDB初期設定ファイル (`.lldbinit`)
プロジェクトのルート、あるいはホームディレクトリに配置し、JITデバッグ時の挙動を最適化する。
~/.lldbinit または プロジェクトローカルの .lldbinit
JITデバッグにおいて、未知の動的ライブラリやJIT領域がロードされた際に
自動的にシンボル情報を探索しに行く設定
settings set target.load-cwd-lldbinit true
例外発生時（セグフォ等）に、自動的に全スレッドのバックトレースを表示する
これにより、JITコード内のクラッシュ原因を即座に把握できる
settings set ꀀtarget.process.stop-on-exec false
逆アセンブルのデフォルトフレーバーをIntel形式に設定（AT&T形式の呪縛からの解放）
settings set target.disassembly-flavor intel
JITで生成された無名関数に対して、人間が判別しやすいカスタムエイリアスを定義
例: `jit-bt` と打つだけで、JIT特有のフレームをフィルタリングして表示
command alias jit-bt thread backtrace –show-inline –count 10
2. 開発効率を10倍にする隠れキーボードショートカット & コマンド
LLDBの対話プロンプトで毎回長いコマンドを打つのは時間の無駄である。LLDBはPythonスクリプトによる拡張が強力なため、 `.lldbinit` に以下を仕込み、瞬時にJITのメモリ状態をダンプできるようにする。
~/.lldbinit 内でPythonスクリプトを読み込み、カスタムコマンドを定義する
script
import lldb
def dump_jit_memory(debugger, command, result, internal_dict):
“””
JIT領域でセグフォが起きた際、周辺のメモリとレジスタ状態を
人間が読める形式で一発出力するカスタムLLDBコマンド
“””
target = debugger.GetSelectedTarget()
process = target.GetProcess()
thread = process.GetSelectedThread()
frame = thread.GetSelectedFrame()
print(f”[] 現在のプログラムカウンタ (PC): {frame.GetPCAddress()}”)
print(f”[] レジスタ状態:”)
for reg in frame.GetRegisters():
if reg.GetName() == “General Purpose Registers”:
for subreg in reg:
print(f” {subreg.GetName()} = {subreg.GetValue()}”)
LLDBコマンドとして登録
lldb.debugger.HandleCommand(‘command script add -f __main__.dump_jit_memory dump-jit’)
end
> 使い方: LLDBのプロンプトで `dump-jit` と叩くだけで、JIT実行中のレジスタとPCアドレスが瞬時にダンプされる。セグフォ時の原因特定スピードが劇的に向上する。
—
5. チーム開発で活きる設定ファイルのベストプラクティス (JSON構成)
複数人のチームで言語処理系やJITコンパイラを開発する場合、VS CodeなどのエディタとLLDBを連携させるデバッグ設定（`launch.json`）の標準化が不可欠である。メンバー全員が同じ環境でワンタッチデバッグを行える構成例を示す。
`.vscode/launch.json` のベストプラクティス
{
“version”: “0.2.0”,
“configurations”: [
{
“name”: “Debug JIT Language Runtime”,
“type”: “lldb”, // CodeLLDB等のLLDBラッパー拡張を使用
“request”: “launch”,
// 自作言語のコンパイラ/ランタイムバイナリへのパス
“program”: “${workspaceFolder}/build/bin/mylang-runtime”,
// デバッグ対象の自作言語ソースファイル
“args”: [“${workspaceFolder}/examples/test_jit.mylang”],
“cwd”: “${workspaceFolder}”,
“stopAtEntry”: false,
// JIT環境下で動的コードのシンボル解決をスムーズに行うための環境変数
“env”: {
“MYLANG_JIT_DEBUG”: “1”,
“LLVM_DISABLE_CRASH_REPORT”: “1”
},
// LLDBが起動した瞬間に実行する初期化コマンド
“initCommands”: [
// JIT領域のブレークポイントを有効化する設定
“settings set target.inline-breakpoint-strategy always”,
// デバッグ情報のキャッシュを有効化し、JIT再コンパイル時の速度を上げる
“breakpoint set –name main”
],
// デバッグセッション開始時にソースパスの置換を行う（Dockerや別階層ビルド対策）
“sourceMap”: {
“/app/src”: “${workspaceFolder}/src”
}
}
]
}
—
6. まとめ：JITデバッグを制する者が言語処理系開発を制する
LLVMを用いたJITコンパイラや動的言語処理系の開発において、「動かしてセグフォしたらおしまい」という時代は終わった。
- `JITEventListener::createGDBRegistrationListener()` を用いて、LLVMとLLDBの間に確実なシンボルの架け橋を作る。
- 最適化された `.lldbinit` とカスタムPythonコマンド（`dump-jit` 等）を駆使し、デバッグの無駄な手順を極限まで排除する。
- チーム全体で `launch.json` を共有し、誰でも一発でJITコードのステップ実行に入れる開発基盤を整える。
このインフラストラクチャを構築した瞬間から、あなたのデバッグ作業は「闇夜の鉄砲撃ち」から「精密な外科手術」へと劇的に生まれ変わるはずだ。妥協のない開発環境構築で、真にモダンな処理系を創り上げてほしい。