GDB のコマンドを手で打ち続けることに、じわじわ疲れてきていませんか。
ブレークポイントを打つたびに break main、変数を見るたびに print、フォークした子プロセスを追うときは set follow-fork-mode child を覚えておかないといけない。
CLI の操作自体はそれほど難しくないのに、頭の片隅でコマンド書式を管理し続けるコストがじわじわとつらいのが正直なところだと思います。
かといって Visual Studio に乗り換えるのも億劫です。
重い、Windows のプロジェクト管理に引きずられる、ライセンスが面倒、という三重苦がある。
VSCode + C/C++ 拡張という選択肢もありますが、あくまで GDB/LLDB のラッパーなので、CLI の不満が根本的に解消されるわけではありません。
そこで今回は raddebugger を試してみた話を書きます。
ビルドから起動・基本操作・マルチプロセスへのアタッチまでを実際に手を動かして確認した流れです。
「自分のプロジェクトで使うかどうか」を判断するための材料になれば十分です。
GDB/LLDBのCLIに疲れたとき、raddebuggerという選択肢
raddebugger は Epic Games が開発し、2024年1月にオープンソースとして公開したデバッガです。
自社のゲームエンジン開発という、世界でも屈指のヘビーなネイティブ C++ 開発環境で磨かれてきたツールという出自があります。
公式の説明は「a native, user-mode, multi-process, graphical debugger」という4つの形容詞で構成されています。
これは単なるキャッチコピーではなく、設計の方針がそのまま出ています。
ネイティブ は OS のデバッグ API を直接使うという意味で、ユーザーモード はカーネルデバッガではないということ。
マルチプロセス は複数プロセスを同時に扱える設計で、グラフィカル は GUI ファーストであることを指しています。
既存の選択肢と比べたとき、raddebugger の立ち位置はどこでしょうか。
GDB/LLDB の CLI は強力ですが、操作を頭に蓄積し続ける必要があります。
ステップ実行はキーボードのみ、変数の状態は自分でクエリを発行しないと見えない、フォーク追跡は設定コマンドを知っていないと詰まる。
「慣れの問題」というより「GUI 向けに設計されていない」という根本的な話で、VSCode 拡張もその限界をそのまま引き継いでいます。
Visual Studio のデバッグ体験そのものは完成されていますが、Windows に縛られる・ソリューションファイルを要求される・起動が遅い、というコストが重い。
raddebugger はその中間を狙っています。
GUI として動いて、しかし依存が少なく、単体バイナリに近い形で動く。
現時点の対応状況について正直に書いておきます。
現行のメインターゲットは Windows x64 + PDB形式のデバッグ情報 です。
Linux x64 は開発中で、libfreetype・libx11・libxext・libxfixes・libxrandr・libgl・libegl といった依存ライブラリが必要で、build.sh でビルドを試せる段階にあります。
DWARF 形式のサポートと Linux ネイティブデバッグは将来対応の予定で、macOS は現時点では視野に入っていません。
ビルドして手元で動かすまで：Windows x64の最短ルート
ゴールを先に示しておきます。
この節が終わった時点では、build フォルダ内に raddbg.exe が生成されていて、コマンドラインか直接実行で GUI ウィンドウが立ち上がっている状態が目標です。
事前に必要なもの は MSVC と Windows SDK の2つだけです。
Visual Studio 本体は不要で、Visual Studio Build Tools からビルドツールだけをインストールすれば足ります。
インストール後、スタートメニューの「Developer Command Prompt for VS」を開くか、vcvarsall.bat x64 を実行したターミナルを用意します。
# リポジトリをクローン
git clone https://github.com/EpicGames/raddebugger.git
cd raddebugger
# MSVCの開発者コンソールからビルドスクリプトを実行
build.bat raddbg
# 成功すると build/ 以下に実行ファイルが生成される
dir build\raddbg.exe
ビルドが通れば build\raddbg.exe が出来上がります。
そのまま実行すると GUI ウィンドウが立ち上がります。
Linux で試したい場合は、先に挙げた依存ライブラリを apt などで揃えてから build.sh を使います。
Ubuntu 系であれば libfreetype-dev・libx11-dev・libxext-dev・libxfixes-dev・libxrandr-dev・libgl-dev・libegl-dev が出発点です。
ただし現時点の Linux 対応は開発途上で、プロダクション用途にはまだ早い段階です。
「試しに動かしてみたい」くらいの温度感で触るのが現実的な向き合い方です。
GUIで完結するデバッグ操作の基本：バイナリを開いてブレークポイントを打つ
raddebugger にバイナリを読み込ませるには、デバッグ情報付きでビルドされた実行ファイルが必要です。
MSVC であればコンパイル時に /Zi と /Od を指定します。
# cl.exe を直接使う場合
cl.exe /Zi /Od /Fe:myapp.exe myapp.cpp /link /DEBUG
# CMake 経由なら Debug ビルドが自動で対応する
cmake -B build -DCMAKE_BUILD_TYPE=Debug
cmake --build build
/Zi で PDB ファイルが生成され、/Od で最適化が無効化されます。
最適化が入ると変数がレジスタに追いやられてウォッチ画面に表示されなくなることがあるので、デバッグビルドでは /Od を忘れずに。
raddebugger を起動したら、File メニューかドラッグ&ドロップで .exe を読み込みます。
このとき内部では radbin という変換ユーティリティが走って、PDB 形式のデバッグ情報を独自の RDI（RAD Debug Info）形式に変換します。
変換は初回のみで、以降はキャッシュされます。
独自フォーマットへの変換を挟むことで、ツールチェーン依存の情報を raddebugger 側で抽象化しているわけです。
ソースコードビューが表示されたら、行番号の横をクリックするだけでブレークポイントが設定されます。
GDB で break myfile.cpp:42 と打っていたあの操作が、クリック1回で終わります。
ステップ実行は画面上部のツールバーに step in・step over・step out が並んでいます。
F10/F11 のキーバインドも使えます。
GDB に慣れているなら最初はキーバインドから入る方が、操作の違和感が少ないかもしれません。
変数ウォッチはローカル変数が自動でパネルに表示されます。
ポインタを展開してメンバを確認したいときは、ツリーを開くだけで済みます。
GDB だと print *ptr を叩いて、さらに print ptr->member を叩いて、という繰り返しが必要だった操作が、ワンクリックで完結する。
この差は使い始めるとじわじわ効いてきます。
動作中のプロセスにアタッチする・複数プロセスを同時に扱う
raddebugger でアタッチするには、起動後のメニューから「Attach to Process」を選びます。
実行中のプロセスの一覧が表示されるので、対象を選んで確定するだけです。
GDB の attach と本質的には同じですが、PID を調べて手で打ち込む手間がない分、ずいぶん楽に感じます。
マルチプロセス構成のデバッグは、raddebugger が最も力を発揮する場面の一つです。
業務システムでよくある構成として、親プロセスがワーカープロセスを複数フォークする、あるいはサービスプロセスと通信ワーカーが共有メモリを介して連携する、といったパターンがあります。
GDB でこれを追うときは、set follow-fork-mode child か parent を先に決めないといけません。
親を追うか子を追うか、その時点で選択を迫られる構造です。
両方を同時に追いたい場合はマルチインフェリア機能を使うことになりますが、設定が煩雑で実務でスムーズに使えるようになるまで時間がかかります。
raddebugger は 複数のターゲットを並列に保持する 設計になっています。
それぞれのプロセスに対して独立してブレークポイントを設定でき、どちらのプロセスで停止しているかをパネルで切り替えながら状態を確認できます。
たとえばサービスプロセスとワーカープロセスが共有メモリ上のキューを介してメッセージをやり取りしているとします。
「サービス側でエンキューした直後にワーカー側のデキュー関数で何が起きているか」を追いたいとき、両方のプロセスにブレークポイントを仕込んで交互に実行を進める操作が、1ウィンドウの中で完結します。
GDB を2ターミナルで並べて PID を手動で管理していたあの作業が、GUI の中に収まる感覚です。
使い続けるかどうかの判断材料：現時点の制約と実務者の声
これが自分のプロジェクトで使えるかどうかは、環境が9割決めます。
Windows x64 で MSVC ビルドの C/C++ バイナリを扱っていて、PDB が生成されるパイプラインをすでに持っているなら、今日から試せます。
一方、Linux 上でネイティブデバッグしたい、GCC や Clang の DWARF 情報をそのまま読み込みたい、macOS で使いたい、という環境には今のところ応えられません。
DWARF サポートと Linux ネイティブデバッグは将来対応として明記されていますが、今は「Windows 限定」と理解しておいた方が期待値のズレが少ない。
実務者コミュニティの反応では、Reddit の r/cpp スレッドで「fast and light on RAM, has every tools you may need for debugging programs」という評価がありました。
Ziggit（Zig コミュニティのフォーラム）でも「On Windows I've had pretty good experiences with RAD Debugger」という声が確認できます。
どちらも Windows 環境という前提付きですが、「軽い・速い」という評価は一貫しています。
Visual Studio のデバッガが嫌いなわけではなく、ただ Visual Studio というスイートごと入れたくない、という感覚に raddebugger はちょうどはまります。
プロジェクトファイルが不要で、バイナリを直接渡すだけで動く手軽さは、ライセンスや環境構築の制約が多い現場で効いてきます。
個人的に、乗り換えを後押しする一番のきっかけは「マルチプロセスのデバッグで GDB を2ターミナル並べた経験があるかどうか」だと思っています。
あの作業がつらかった記憶がある人ほど、raddebugger を触ったときの「これでよかったのか」という感覚が大きい。
Windows 環境のプロジェクトで使える状況にあるなら、ビルドして一度動かしてみるだけの価値はあります。
株式会社ホコサキは山口県宇部市を拠点に、Web制作・業務システム開発・AI活用支援・DX推進を手がけています。
ネイティブ開発環境の構成や開発ツールの選定についても実務レベルでご相談いただけます。
お気軽に お問い合わせページ からご連絡ください。