プログラムをGDB配下で実行するには、 コンパイル時にデバッグ情報を生成する必要があります。
ユーザが選択した環境で、 必要に応じて引数を指定して、 GDBを起動することができます。 ネイティブ環境でデバッグを行っているのであれば、 プログラムの入力元と出力先をリダイレクトすること、 既に実行中のプロセスをデバッグすること、 子プロセスを終了させることもできます。
プログラムを効率的にデバッグするためには、 そのプログラムのコンパイル時にデバッグ情報を生成する必要があります。 このデバッグ情報はオブジェクト・ファイルに格納されます。 この情報は、 個々の変数や関数の型、 ソース・コード内の行番号と実行形式コードのアドレスとの対応などを含みます。
デバッグ情報の生成を要求するには、 コンパイラの実行時に`-g'オプションを指定します。
多くのCコンパイラでは、 `-g'オプションと`-O'オプションを同時に指定することができません。 このようなコンパイラでは、 デバッグ情報付きの最適化された実行ファイルを生成することができません。
GNUのCコンパイラであるGCCは、 `-O'オプションの有無にかかわらず、 `-g'オプションが指定できます。 したがって、 最適化されたコードをデバッグすることが可能です。 プログラムをコンパイルするときには、 常に`-g'オプションを指定することをお勧めします。 自分のプログラムは正しいと思うかもしれませんが、 自分の幸運を信じて疑わないというのは無意味なことです。
`-g -O'オプションを指定してコンパイルされたプログラムをデバッグするときには、 オプティマイザがコードを再調整していることを忘れないでください。 デバッガは、 実際に存在するコードの情報を表示します。 実行されるパスがソース・ファイルの記述と一致していなくても、 あまり驚かないでください。 これは極端な例ですが、 定義されているが実際には使われていない変数を、 GDBは認識しません。 なぜなら、 コンパイラの最適化処理により、 そのような変数は削除されるからです。
命令スケジューリング機能を持つマシンなどでは、 `-g'を指定してコンパイルされたプログラムでは正しく動作することが、 `-g -O'を指定してコンパイルされたプログラムでは正しく動作しないということがあります。 `-g -O'を指定してコンパイルされたプログラムのデバッグで何かおかしな点があれば、 `-g'だけを指定してコンパイルしてみてください。 これで問題が解決するようであれば、 （再現環境と一緒に） 障害として私たちに報告してください。
古いバージョンのGNU Cコンパイラは、 デバッグ情報の生成のためのオプションの1つとして `-gg'をサポートしていました。 現在のGDBはこのフォーマットをサポートしていません。 お手元のGNU Cコンパイラにこのオプションがあるようであれば、 それは使わないでください。
run
r
runコマンドを使用してください。
（VxWorks以外の環境では）
最初にプログラム名を指定する必要があります。
これには、
GDBへの引数を使用する方法
（GDBの起動と終了参照）
と、
fileコマンドまたはexec-fileコマンドを使用する方法
（ファイルを指定するコマンド参照）
とがあります。
プロセスをサポートする環境でプログラムを実行している場合、
runコマンドは下位プロセスを生成し、
そのプロセスにプログラムを実行させます
（プロセスをサポートしていない環境では、
runコマンドはプログラムの先頭アドレスにジャンプします）。
プログラムの実行は、 上位プロセスから受け取る情報によって影響されます。 GDBはこの情報を指定する手段を提供しています。 これは、 ユーザ・プログラムが起動される前に実行されていなければなりません （ユーザ・プログラムの実行後にその情報を変更することも可能ですが、 その変更結果は、 次にプログラムを実行したときに初めて有効になります）。 この情報は、 4つに分類することができます。
runコマンドへの引数として指定します。
ターゲット上でシェルが使用可能であれば、
引数を表現するのに通常使用する手法
（例えば、
ワイルドカード拡張や変数置換など）
が利用できるよう、
シェルを経由して引数を渡します。
UNIXシステムでは、
SHELL環境変数によって、
使用されるシェルを選択することができます。
ユーザ・プログラムの引数
を参照してください。
set environmentコマンドと
unset environmentコマンドを使用して、
ユーザ・プログラムの実行に影響する環境の一部を変更することができます。
ユーザ・プログラムの環境
を参照してください。
cdコマンドで設定可能です。
ユーザ・プログラムの作業ディレクトリ
を参照してください。
runコマンドのコマンド・ライン上で、
標準入力、
標準出力をリダイレクトすることも可能です。
また、
ttyコマンドによって別のデバイスを割り当てることも可能です。
ユーザ・プログラムの入出力
を参照してください。
注意：入出力のリダイレクトは機能しますが、
デバッグ中のプログラムの出力を、
パイプを使用して他のプログラムに渡すことはできません。
このようなことをすると、
GDBは誤って、
別のプログラムのデバッグを開始してしまうでしょう。
runコマンドを実行すると、
ユーザ・プログラムはすぐに実行を始めます。
プログラムを停止させる方法については、
停止と継続
を参照してください。
プログラムが停止すると、
printコマンドまたはcallコマンドを使用して、
プログラム内の関数を呼び出すことができます。
データの検査
を参照してください。
GDBが最後にシンボル情報を読み込んだ後に、 シンボル・ファイルの修正タイムスタンプが変更されている場合、 GDBはシンボル・テーブルを破棄して、 再読み込みを行います。 この場合、 GDBは、 その時点におけるブレイクポイントの設定を保持しようと試みます。
ユーザ・プログラムへの引数は、
runコマンドへの引数によって指定可能です。
それはまずシェルに渡され、
ワイルドカードの展開やI/Oのリダイレクトの後、
プログラムに渡されます。
SHELL環境変数によって、
GDBの使用するシェルが指定されます。
SHELL環境変数が定義されていないと、
GDBはデフォルト・シェル
（UNIXでは/bin/sh）
を使用します。
UNIX以外のシステムでは通常、 プログラムはGDBによって直接起動されます。 I/Oのリダイレクトは、 適切なシステム・コールを使用してGDBがエミュレートします。 またワイルドカード文字は、 シェルではなく、 プログラムのスタートアップ・コードによって展開されます。
引数を指定せずに
runコマンドを実行すると、
前回runコマンドを実行したときの引数、
または、
set argsコマンドでセットされた引数が使用されます。
set args
set argsが引数なしで実行された場合、
runコマンドは、
ユーザ・プログラムを引数なしで実行します。
一度プログラムに引数を指定して実行すると、
次にプログラムを引数なしで実行する唯一の方法は、
runコマンドを実行する前に
set argsコマンドを実行することです。
show args
環境とは、 環境変数とその値の集合のことです。 環境変数は、 慣例として、 ユーザ名、 ユーザのホーム・ディレクトリ、 端末タイプ、 実行プログラムのサーチ・パスなどを記録します。 通常、 環境変数はシェル上で設定され、 ユーザの実行するすべてのプログラムによって継承されます。 デバッグ時には、 GDBを終了・再起動せずに環境を変更して、 ユーザ・プログラムを実行できると便利でしょう。
path directory
PATH
（実行ファイルのサーチ・パス）
の先頭に追加します。
これは、
GDBとユーザ・プログラムの両方に対して有効です。
空白類、
または、
システム依存の区切文字
（UNIXでは`:'、
MS-DOSとMS-Windowsでは`;'）
で区切られた複数のディレクトリを指定することもできます。
環境変数PATHの中に既にdirectoryが含まれている場合には、
directoryは環境変数PATHの先頭に移動されます。
これにより、
directoryはより早く検索されることになります。
文字列`$cwd'によって、
GDBがパスを検索する時点における作業ディレクトリを参照することができます。
`.'
（ピリオド）
を使用すると、
pathコマンドを実行したディレクトリを参照することになります。
directory引数に`.'
（ピリオド）
が含まれていると、
GDBはまずそれを
（カレント・ディレクトリに）
置き換えてから、
directoryをサーチ・パスに追加します。
show paths
PATHの値）を表示します。
show environment [varname]
environmentはenvに省略可能です。
set environment varname [=value]
set env USER = foo
unset environment varname
unset environmentは、
環境変数の値として空文字列をセットするのではなく、
環境変数そのものを環境から削除します。
注意：UNIXシステムでは、
GDBは、
環境変数SHELLにより指定されるシェル
（環境変数SHELLが設定されていない場合には/bin/sh）
を使用してプログラムを実行します。
SHELL環境変数の指定するシェルが初期化ファイルを実行するものである場合
（例えば、
C-shellの`.cshrc'、
BASHの`.bashrc'）、
初期化ファイルの中で設定された環境変数はユーザ・プログラムに影響を与えます。
環境変数の設定は、
`.login'や`.profile'のように、
ユーザがシステム内に入るときにのみ実行されるファイルに移したほうがよいでしょう。
runコマンドで実行されるユーザ・プログラムは、
実行時のGDBの作業ディレクトリを継承します。
GDBの作業ディレクトリは、
もともと親プロセス
（通常はシェル）
から継承したものですが、
cdコマンドによって、
GDBの中から新しい作業ディレクトリを指定することができます。
GDBの作業ディレクトリは、 GDBによって操作されるファイルを指定するコマンドに対して、 デフォルト・ディレクトリとして機能します。 ファイルを指定するコマンド を参照してください。
cd directory
pwd
GDB配下で実行されるプログラムは、 デフォルトでは、 GDBと同一の端末に対して入出力を行います。 GDBは、 ユーザとのやりとりのために、 端末モードをGDB用に変更します。 このとき、 ユーザ・プログラムが使用していた端末モードは記録され、 ユーザ・プログラムを継続実行すると、 そのモードに戻ります。
info terminal
runコマンドにおいてシェルのリダイレクト機能を使用することによって、
ユーザ・プログラムの入出力をリダイレクトすることが可能です。
例えば、
run > outfile
はユーザ・プログラムの実行を開始し、 その出力をファイル`outfile'に書き込みます。
ユーザ・プログラムの入出力先を指定する別の方法に、
ttyコマンドがあります。
このコマンドはファイル名を引数として取り、
そのファイルを後に実行されるrunコマンドのデフォルトの入出力先とします。
このコマンドはまた、
後のrunコマンドにより生成される子プロセスを制御する端末を変更します。
例えば、
tty /dev/ttyb
は、
それ以降に実行されるrunコマンドによって起動されるプロセスの
デフォルトの入出力先および制御端末を`/dev/ttyb'端末とします。
runコマンド実行時に明示的にリダイレクト先を指定することで、
ttyコマンドで指定された入出力装置を変更することができますが、
制御端末の設定は変更できません。
ttyコマンドを使用した場合も、
runコマンドで入力をリダイレクトした場合も、
ユーザ・プログラムの入力元だけが変更されます。
これらのコマンドを実行しても、
GDBの入力元は、ユーザの使用している端末のままです。
attach process-id
info filesコマンドで、
現在デバッグ対象となっているプログラムの情報が表示されます）。
このコマンドは、
プロセスIDを引数に取ります。
UNIXプロセスのプロセスIDを知るのに通常使用する方法は、
psユーティリティ、
または、
シェル・コマンドの`jobs -l'の実行です。
attachコマンドを実行後RETキーを押しても、
コマンドは再実行されません。
attachコマンドを使用するには、
プロセスをサポートする環境でユーザ・プログラムを実行する必要があります。
例えば、
オペレーティング・システムの存在しないボード・コンピュータのような環境で動作するプログラムに対して、
attachコマンドを使うことはできません。
さらに、
ユーザは、
プロセスに対してシグナルを送信する権利を持っている必要があります。
attachコマンドを使用すると、
デバッガは、
まずカレントな作業ディレクトリの中で、
プロセスにより実行されているプログラムを見つけようとします。
（プログラムが見つからなければ）
次に、
ソース・ファイルのサーチ・パス
（ソース・ディレクトリの指定参照）
を使用して、
プログラムを見つけようとします。
fileコマンドを使用して、
プログラムをロードすることも可能です。
ファイルを指定するコマンド
を参照してください。
指定されたプロセスをデバッグする準備が整った後に、
GDBが最初にすることは、
そのプロセスを停止することです。
runコマンドを使用してプロセスを起動した場合は、
通常使用可能なすべてのGDBコマンドを使用して、
アタッチされたプロセスの状態を調べたり変更したりすることができます。
ブレイクポイントの設定、
ステップ実行、
継続実行、
記憶域の内容の変更が可能です。
プロセスの実行を継続したいのであれば、
GDBがプロセスにアタッチした後に、
continueコマンドを使用することができます。
detach
detachコマンドを使用してそのプロセスをGDBの管理から解放することができます。
プロセスからディタッチしても、
そのプロセスは実行を継続します。
detachコマンド実行後は、
ディタッチされたプロセスと
GDBは互いに完全に依存関係がなくなり、
attachコマンドによる別のプロセスへのアタッチや、
runコマンドによる別のプロセスの起動が可能になります。
detachコマンドを実行後RETキーを押しても、
detachコマンドは再実行されません。
プロセスがアタッチされている状態で、
GDBを終了したりrunコマンドを使用したりすると、
アタッチされたプロセスを終了させてしまいます。
デフォルトの状態では、
このようなことを実行しようとすると、
GDBが確認を求めてきます。
この確認処理を行うか否かは、
set confirmコマンドで制御可能です
（オプションの警告およびメッセージ参照）。
kill
このコマンドは、 実行中のプロセスではなく、 コア・ダンプをデバッグしたいときに便利です。 GDBは、 ユーザ・プログラムの実行中は、 コア・ダンプ・ファイルを無視します。
いくつかのオペレーティング・システム上では、
GDBの管理下でブレイクポイントを設定されている状態のプログラムを、
GDBの外で実行することができません。
このような場合、
killコマンドを使用することで、デバッガの外でのプログラムの実行が可能になります。
killコマンドは、
プログラムを再コンパイル、
再リンクしたい場合にも便利です。
というのは、
多くのシステムでは、
プロセスとして実行中の実行ファイルを更新することはできないからです。
次にrunコマンドを実行したときに、
GDBは、
実行ファイルが変更されていることを認識し、
シンボル・テーブルを再度読み込みます
（この際、その時点でのブレイクポイントの設定を維持しようと試みます）。
HP-UXやSolarisのようなオペレーティング・システムにおいては、 1つのプログラムが複数のスレッドを実行することができます。 「スレッド」の正確な意味は、 オペレーティング・システムによって異なります。 しかし、 一般的には、 1つのアドレス空間を共有するという点を除けば、 プログラム内のマルチスレッドは、 マルチプロセスと類似しています （アドレス空間の共有とは、 複数のスレッドが同一の変数の値を参照したり変更したりすることが可能であるということです）。 その一方で、 個々のスレッドは自分用のレジスタ、 実行スタック、 そしておそらくはプライベート・メモリを持ちます。
GDBは、 マルチスレッド・プログラムのデバッグ用に、 以下のような便利な機能を提供しています。
注意：これらの機能は、 スレッドをサポートするオペレーティング・システムをターゲットとしてconfigureによって構成された すべてのGDBで使用可能なわけではありません。 GDBがスレッドをサポートしていない環境では、 これらのコマンドは無効です。 例えば、 スレッドをサポートしていないシステム上で GDBの`info threads'コマンドを実行しても何も表示されませんし、
threadコマンドの実行は常に拒絶されます。(gdb) info threads (gdb) thread 1 Thread ID 1 not known. Use the "info threads" command to see the IDs of currently known threads.
GDBのスレッド・デバッグ機能により、 ユーザ・プログラムの実行中に、 すべてのスレッドを観察することができます。 ただし、 GDBに制御権のある状態では、 特定の1つのスレッドだけがデバッグの対象となります。 このスレッドは、 カレント・スレッドと呼ばれます。 デバッグ用のコマンドは、 カレント・スレッドの立場から見たプログラムの情報を表示します。
ユーザ・プログラム内部において新しいスレッドの存在を検出すると、 GDBは、 `[New systag]'という形式で、 ターゲット・システム上におけるこのスレッドのIDを表示します。 ここでsystagとはスレッドのIDで、 その形式はシステムによって異なります。 例えば、 LynxOS上では、 GDBが新しいスレッドを検出すると、
[New process 35 thread 27]
のように表示されます。 一方、 SGIのシステム上では、 systagは単に`process 368'のような形式で、 これ以外の情報は含まれません。
GDBは、 デバッグを行うために、 ユーザ・プログラム内の個々のスレッドに対して整数値のスレッド番号を独自に割り当てます。
info threads
(gdb) info threads
3 process 35 thread 27 0x34e5 in sigpause ()
2 process 35 thread 23 0x34e5 in sigpause ()
* 1 process 35 thread 13 main (argc=1, argv=0x7ffffff8)
at threadtest.c:68
HP-UXシステムでは以下のようになります。
GDBは、 デバッグを行うために、 独自のスレッド番号 --スレッドの生成順に割り当てられるサイズの小さい整数値-- を、 ユーザ・プログラムの個々のスレッドに割り当てます。
GDBは、 ユーザ・プログラムの中に新しいスレッドの存在を検出するたびに、 `[New systag]'という形式のメッセージで、 GDBのスレッド番号とそのスレッドに対するターゲット・システムの識別子を表示します。 systagはスレッドのIDで、 その形式はシステムによって異なります。 例えば、 HP-UX上では、 GDBが新しいスレッドの存在を検出すると、
[New thread 2 (system thread 26594)]
というメッセージが表示されます。
info threads
(gdb) info threads
* 3 system thread 26607 worker (wptr=0x7b09c318 "@") \
at quicksort.c:137
2 system thread 26606 0x7b0030d8 in __ksleep () \
from /usr/lib/libc.2
1 system thread 27905 0x7b003498 in _brk () \
from /usr/lib/libc.2
thread threadno
(gdb) thread 2 [Switching to process 35 thread 23] 0x34e5 in sigpause ()`[New ...]'メッセージと同様、 `Switching to'の後ろに表示される情報の形式は、 そのシステムにおけるスレッドの識別方法に依存します。
thread apply [threadno] [all] args
thread applyコマンドにより、
1つのコマンドを1つ以上のスレッドに対して実行することができます。
実行対象となるスレッドのスレッド番号を、
引数threadnoに指定します。
threadnoは、
`info threads'コマンドの出力の最初のフィールドに表示される、
GDB内部のスレッド番号です。
すべてのスレッドに対してコマンドを実行するには、
thread apply all argsコマンドを使用してください。
GDBがユーザ・プログラムを停止させるとき、 その理由がブレイクポイントであれシグナルの受信であれ、 ブレイクポイントに到達したスレッド、 または、 シグナルを受信したスレッドが自動的に選択されます。 GDBは、 `[Switching to systag]'という形式のメッセージでそのスレッドを示し、 コンテキスト切り替えの発生に注意を促します。
複数スレッドを持つプログラムの停止時や起動時のGDBの動作の詳細については、 マルチスレッド・プログラムの停止と起動 を参照してください。
また、 複数スレッドを持つプログラムの中におけるウォッチポイントについては、 ウォッチポイントの設定 を参照してください。
ほとんどのシステムにおいてGDBは、
fork関数を使用して新たにプロセスを生成するプログラムのデバッグに関して特別な機能を提供していません。
プログラムがforkを実行するとき、
GDB
は引き続き親プロセスのデバッグを継続し、
子プロセスは妨げられることなく実行されます。
子プロセスが実行するコードにブレイクポイントを設定してあると、
子プロセスはSIGTRAPシグナルを受信し、
（そのシグナルをキャッチする処理がなければ）
子プロセスは終了してしまいます。
しかし、
子プロセスをデバッグしたい場合には、
それほど困難ではない回避策があります。
forkの呼び出し後に子プロセスが実行するソース・コードの中に、
sleep関数の呼び出しを加えてください。
GDBに子プロセスのデバッグをさせる理由がないときに遅延が発生することのないように、
特定の環境変数が設定されているときや特定のファイルが存在するときのみ、
sleep関数を呼び出すようにするとよいでしょう。
子プロセスがsleepを呼び出している間に、
psユーティリティを使用して子プロセスのプロセスIDを獲得します。
次に、
GDBに対して
（親プロセスもデバッグするのであれば、
新たにGDBを起動して、
そのGDBに対して）、
子プロセスにアタッチするよう指示してください
（既に実行中のプロセスのデバッグ参照）。
これ以降は、
通常の方法でプロセスにアタッチした場合と全く同様に、
子プロセスのデバッグが可能です。
これに対してHP-UX
（おそらくバージョン11.x以降のみであると思われますが）
上のGDBは、
fork関数、
または、
vfork関数を使用して新たにプロセスを生成するプログラムのデバッグをサポートしています。
デフォルトでは、
プログラムがforkを実行するとき、
GDBは、
引き続き親プロセスのデバッグを継続し、
子プロセスは、
妨げられることなく実行されます。
親プロセスではなく子プロセスの実行を追跡したい場合は、
コマンドset follow-fork-modeを使用します。
set follow-fork-mode mode
forkやvforkの呼び出しに反応するよう、
デバッガを設定します。
forkやvforkの呼び出しは、
新しいプロセスを生成します。
modeは、
以下のいずれかです。
parent
forkの後、
元のプロセスをデバッグします。
子プロセスは、
妨げられることなく実行されます。
これがデフォルトです。
child
forkの後、
新しいプロセスをデバッグします。
親プロセスは、
妨げられることなく実行されます。
ask
show follow-fork-mode
forkやvforkの呼び出しに対して、
現在、
デバッガがどのように反応するよう設定されているかを表示します。
子プロセスをデバッグするよう要求されているときに、
vforkに続けてexecが呼び出されると、
GDBは、
新しいターゲットを、
設定されている最初のブレイクポイントまで実行します。
元のプログラムのmainにブレイクポイントがセットされていると、
子プロセスのmainにもブレイクポイントがセットされます。
子プロセスがvforkによって生成（spawn）された場合、
execの呼び出しが完了するまで、
子プロセス、
親プロセスのどちらもデバッグすることはできません。
execの呼び出し後に、
GDBに対してrunコマンドを発行すると、
新しいターゲットが再始動されます。
親プロセスを再始動するには、
親プロセスの実行ファイル名を引数に指定して、
fileコマンドを使用します。
catchコマンドを使用することによって、
fork、
vfork、
execの呼び出しが行われるたびに、
GDBを停止させることができます。
キャッチポイントの設定
を参照してください。