GNUデバッガ(単にGDBとも)は、GNUソフトウェア・システムで動く標準のデバッガである。これは、多くのUnix系システムで動作可能な移植性の高いデバッガであり、Ada、C言語、C++、Objective-C、Pascal、FORTRAN、FreeBASIC、Goといったプログラミング言語に対応している。

## 歴史

GDBは初め、GNU Emacs が「そこそこ安定化」した後、1986年 にGNU システムの一部として リチャード・ストールマン が書いた。GDBは、GNU General Public License (GPL) の下でリリースしている 自由ソフトウェア である。これは、BSDに付属していたdbxデバッガをモデルにしている。

1990年から1993年まではジョン・ギルモアが保守をしていた。現在はFree Software Foundationによって任命されたGDB運営委員会によって保守されている。

## 技術詳細

### 機能

GDBは、プログラムの実行の変更や追跡といった充実した機能を提供する。プログラム内部の 変数 の値を修正したり、監視したりすることや、プログラムの通常の動作とは別に 関数 を呼び出すことができる。

2003年 現在、GDBのターゲット・プロセッサは、以下のとおりである。

- Alpha
- ARM
- AVR
- Altera Nios/Nios II
- H8/300
- System/370 / System 390
- x86 / x64
- IA-64「Itanium」
- Motorola 68000
- MIPS
- PA-RISC
- PowerPC
- SuperH
- SPARC
- VAX

標準リリースでサポートされている、さほど有名でないターゲット・プロセッサには、以下がある。

- AMD 29000
- ARC
- CRIS
- D10V / D30V
- FR-30 / FR-V
- Intel i960
- M32R
- 68HC11
- Motorola 88000
- MCORE
- MN10200 / MN10300
- NS32K
- Stormy16
- V850
- Z8000

新しいリリースでは、これらの一部をサポートしていない可能性がある。GDBには、M32RやV850といった、日本製のCPUをターゲットにしたコンパイル済みのシミュレータがある。

GDBはまだ活発に開発されている。バージョン7.0の新機能には、Pythonスクリプトのサポートが含まれ、バージョン7.8ではGNU Guileスクリプトもサポートされている。バージョン7.0からは「リバーシブルデバッグ」がサポートされている。これは、クラッシュしたプログラムを巻き戻して何が起こったのかを確認するように、デバッグセッションを後退させることができる。

### 遠隔デバッグ

GDBには「遠隔」モードがあり、しばしば組込みシステムのデバッグで使われる。遠隔操作では、GDBとデバッグ対象のプログラムは別のマシンで動作する。GDBは、GDBプロトコルをシリアルやTCP/IP経由で理解する遠隔「スタブ」と通信することができる。スタブプログラムは、通信プロトコルのターゲット側を実装したGDB付属の適切なスタブファイルにリンクすることで作成できる。または、gdbserverを使用して、プログラムを変更せずにリモートでデバッグすることもできる。

GDBを使い、動いているLinuxカーネルをソース・レベルでデバッグするKGDBでも、同じモードを使っている。KGDBを使い、カーネル開発者は、アプリケーション・プログラムのようにカーネルをデバッグできる。カーネル・コードにブレークポイントを設定でき、ステップ動作ができ、変数を参照できる。ハードウェアのデバッグ・レジスタ (debugging register) が使えるアーキテクチャでは、ウォッチポイントが設定できる。ウォッチポイントとは、特定のメモリー・アドレスを実行したり、アクセスしたときのブレークポイントをかけるものである。KGDBには、シリアルケーブルやイーサネットを使ってデバッグ対象マシンに繋がったマシンが必要となる。FreeBSDでは、FireWire DMAを使ったデバッグもできる。

### グラフィカルユーザーインタフェース

このデバッガは、グラフィカルユーザインタフェース (GUI) は含まれておらず、デフォルトはコマンドラインユーザインタフェース (CUI) である。UltraGDB、Xxgdb、Data Display Debugger (DDD)、Nemiver、KDbg、Xcode デバッガ、GDBtk/Insight、HP Wildebeest Debugger GUI (WDB GUI) など、いくつかのフロントエンドが構築されている。Codelite、Code::Blocks、Dev-C++、Geany、GNAT Programming Studio (GPS)、KDevelop、Qt Creator、Lazarus、MonoDevelop、Eclipse、NetBeans、Visual Studioなどの統合開発環境は、GDBとインターフェースをとることができる。GNU Emacsには「GUDモード」があり、VIM用のツールが存在する(例: clewn)。これらのツールはIDEにあるデバッガと同様の機能を提供する。

他にも、メモリリーク検出器など、GDBと連動するように設計されたデバッグツールもある。

## コマンド例

|  |  |
| --- | --- |
| `gdb program` | "program" をデバッグ (シェル上で操作) |
| `run -v` | ロードされたprogramをパラメータを指定して実行 |
| `bt` | バックトレース (programがクラッシュした場合) |
| `info registers` | すべてのレジスタをダンプ |
| `disas $pc-32, $pc+32` | 逆アセンブル(等価なコマンドは x/64i $pc-32 ) |

## セッション例

C言語で書かれた以下のソースコードを考える。

Linux上のGCCコンパイラを使用する場合、生成されたバイナリに適切なデバッグ情報を含めるために`-g`フラグを使用して上記のコードをコンパイルしなければならない。これにより、GDBを使用してバイナリを検査できる。上記のコードを含むファイルが `example.c` という名前であると仮定すると、コンパイルのためのコマンドは次の様になる。

そして、バイナリを実行できるようになった。

サンプルコードを実行するとセグメンテーションフォールトが発生するので、GDBを使用して問題を検査することができる。

この問題は8行目にあり、`strlen`関数を呼び出す際に発生する (引数 `s` が `NULL` であるため)。strlen の実装 (インライン関数かどうか) に応じて出力が異なる場合がある。

コマンド `bt` でプログラムのスタック・トレースをとると、`main`関数からソースコードの階層を降りて`strlen`関数が呼び出されている流れを確かめられる。

この問題を修正するには、変数 `a` (`main`関数内) に有効な文字列を含まなければならない。コードの修正版は次の通りである。

GDB内で実行ファイルを再コンパイルして実行すると、正しい結果が得られるようになった。

GDBは `printf` の出力を画面に表示し、プログラムが正常に終了したことをユーザに知らせる。