![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
参考URL
gdb でデバッグしていて、ソースコードが表示されない場合、対象プログラムが、-g オプション指定でコンパイルされているか、確認をする。-g オプションは、デバッグ情報を追加するための、オプションである。
参考URL
$ gdb [exefile] (gdb) break [function] (gdb) run (args) (gdb) s 5 (gdb) s (gdb) s
動作を確認したい関数へ breakpoint を貼り、ソースコードを一行ずつ実行していく。
$ gdb [exefile] (gdb) run (args) ..Some Error Message.. (gdb)
エラーや例外で停止する場合は、とにかく run で実行をして、出力されるエラーメッセージを、ソースファイル名と行数が書かれているか、確認する。
$ gdb [exefile] (gdb) break main (gdb) run (args) (gdb) s 1000 (gdb) s 100 (gdb) s (gdb) ...
ソースなどの情報が表示されない場合は、恐らくデバッグ情報なしのライブラリを使用している。この場合は、main などに breakpoint を貼り、ステップ実行で問題箇所の当たりを付けていく。
コアを吐くエラーの場合は、下記のようにして、再現ができる。
gdb -c corefile exefile
その後、whereコマンドで、エラー状態をスタック形式で見ることが出来る。
(gdb) where
上から順に読み進み、問題が発生していると思われる箇所を、特定する。
(gdb) break <クラス名>::<関数名> (gdb) break <ファイル名>:<行番号> (gdb) break <ファイル名>:<関数名>
breakpoint が貼れない場合、一度 run を実行すると、貼れる場合がある。良く利用するのは、関数名による指定。他は、ファイル名:行番号。
更に細かく見る場合は、メモリアドレスを直接指定する。余程のことがない限り、使わない。
(gdb) break *{アドレス}
※"*"を忘れずに
breakpoint の削除は、以下のコマンドを使う。
(gdb) delete
breakpoint の一覧は、以下のコマンドを使う。
(gdb) info breakpoints
複数 breakpoint を貼った、或いは複数回呼ばれる場合、次の breakpoint 呼び出しまでの処理を、一気に行なう。途中に無限ループがある場合は、処理が戻らないので注意。
複数の関数をデバッグする際に、次の breakpoint まで移動するために利用する。
各変数の値などを表示する。ポインタ変数の場合は、先頭に"*"を付加することで、 実際の中身が表示される。キャストをして、表示することも出来る。
(gdb) p <変数名>
実際には以下のように書く。
(gdb) p num (gdb) p *struct
変数に、値の設定が出来る。エラー箇所にて、もし別の値が設定されていた場合、どういう挙動をするか、確認したい場合に、時々利用する。
(gdb) watch <変数名>
指定した変数の値が変化すると、通知する。あまり活用はしていない。
(gdb) p <変数名>
変数のメモリアドレスが表示される。
(gdb) p *<アドレス>
そのアドレスの値を表示することで、スコープ外でもメモリ上の値を参照できる。知らぬ間にメモリ上の内容が破壊されてるケースで、有効。
