#author("2021-05-21T18:45:11+00:00","","") #author("2022-12-30T00:18:24+09:00","","") #topicpath ///////////////////////////////////////////////////////////////////////////////// * 目次 [#eff751c0] #contents(); ///////////////////////////////////////////////////////////////////////////////// * 起動オプション [#a04ac3e7] |~section |~option |~description |~remark | |Select Files |<file>&br;--exec=<file> |実行形式ファイルとして <file> を指定 | | |~|-c <file>&br;--core=<file> |core ファイルとして <file> を指定 | | |~|--se=<file> |シンボルファイル及び実行形式ファイルとして <file> を指定 | | |~|--symbols=<file> |シンボルフィルとして <file> を指定 | | |Output and user interface control |--tui |''T''erminal が ''U''ser ''I''nterface であるものとして扱う。 |ターミナルの画面を上下2分割し、上半分にソースコード、下半分に通常の gdb の入出力画面が表示される | |~|-w |GUI を使用する | | |Operating modes |--configuration |gdb の設定内容の詳細を表示して終了する | | |other |--cd=<dir> |Currente Directory を <dir> にする | | |remote debugging options |-b <BAUDRATE> |serial port の baud rate を指定 | | |~|-l <TIMEOUT> |リモードでバッグにおけるタイムアウトを <TIMEOUT>[sec] に設定する | | |batch |-batch |バッチ処理モードで起動。 | | |batch |-x <command-file> |バッチ処理モードで実行する gdb のコマンドファイルを指定する。 | | ///////////////////////////////////////////////////////////////////////////////// * core file から bcaktrace を見る [#qe040af5] - プログラムが SIGSEGV などのシグナルで死んだ場合に、吐き出された core ファイルを使って、落ちた箇所の特定をする ++ プログラムを実行し、コアダンプが発生する $ ./TestProg CATest::SetEventQueue: [event_queue:0x7ffdf43294e0] Push: [queue_num:01][EVENT_ID:RUN] Pop(2): [queue_num:00][EVENT_ID:01:RUN] Push: [queue_num:01][EVENT_ID:INVALID] Pop(2): [queue_num:00][EVENT_ID:04:INVALID] Trace/breakpoint trap (コアダンプ) ++ gdb を起動。プロンプト "''(gdb)''" が表示される。 $ gdb (gdb) ++ プログラムを読み込む (gdb) file ./TestProg Reading symbols from TestProg...(no debugging symbols found)...done. ++ core ファイルを読み込む (gdb) core-file core [New LWP 15174] [New LWP 15173] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `./TestProg'. Program terminated with signal SIGTRAP, Trace/breakpoint trap. #0 0x00007f8f523dc79b in raise (sig=5) at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:37 37 ../nptl/sysdeps/unix/sysv/linux/pt-raise.c: そのようなファイルやディレクトリはありません. (gdb) ++ backtrace を表示させる (gdb) bt #0 0x00007f8f523dc79b in raise (sig=5) at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:37 #1 0x0000000000404c47 in SigsegvWorkerThread ( p_args=<error reading variable: can't compute CFA for this frame>) at SigsegvWorkerThread.cpp:63 #2 0x0000000000404abc in std::_Bind_simple<void (*(CSigsegvWorkerThreadArgs*))(CSigsegvWorkerThreadArgs*)>::_M_invoke<0ul>(std::_Index_tuple<0ul>) ( this=<error reading variable: can't compute CFA for this frame>) at /usr/include/c++/4.9/functional:1700 #3 0x00000000004049b5 in std::_Bind_simple<void (*(CSigsegvWorkerThreadArgs*))(CSigsegvWorkerThreadArgs*)>::operator()() (this=<error reading variable: can't compute CFA for this frame>) at /usr/include/c++/4.9/functional:1688 #4 0x0000000000404932 in std::thread::_Impl<std::_Bind_simple<void (*(CSigsegvWorkerThreadArgs*))(CSigsegvWorkerThreadArgs*)> >::_M_run() ( this=<error reading variable: can't compute CFA for this frame>) at /usr/include/c++/4.9/thread:115 #5 0x00007f8f526a0970 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #6 0x00007f8f523d50a4 in start_thread (arg=0x7f8f51b0a700) at pthread_create.c:309 #7 0x00007f8f51bf387d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 (gdb) --- この例では、SigsegvWorkerThread() から呼びだされている raise() で落ちている。(そもそも raise() はそういうことをするための関数なのだが、ここはこういった例示の為のサンプルプログラムなので...) ///////////////////////////////////////////////////////////////////////////////// * 実行形式からデバッグシンボルが分離されている場合 [#c03d2376] - 実行形式とデバッグシンボルが別ファイルになっている場合がある -- クラッキング対策などの理由で、実行形式からデバッグシンボルを strip した場合は、実行形式にデバッグシンボルが全く残っていない。 -- そうはいってもデバッグに困るので、別ファイルにデバッグシンボルのみを保存する場合がある - こうした場合は、実行形式とデバッグシンボルを別々に読み込む ++ 実行形式の読み込み (gdb) file ./TestProg Reading symbols from TestProg...(no debugging symbols found)...done. (gdb) ++ デバッグシンボルファイルの読み込み (gdb) symbol-file TestProg.sym Load new symbol table from "TestProg.sym"? (y or n) y Reading symbols from TestProg.sym...done. (gdb) - ここまで出来たら、core ファイルを読み込んで解析したり、或いは break で break point を張って run でデバッグ実行したりする。 ///////////////////////////////////////////////////////////////////////////////// * debug 実行 [#c2b991e4] ///////////////////////////////////////////////////////////////////////////////// ** コマンド [#ne4a16a8] - break, b <break-point> -- breakpoint を指定する -- breakpoint には、下記を指定する ファイル名:行番号 シンボル名(関数名) アドレス - backtrace -- バックトレースを表示する -- 書式 bt [file:]function bt [file:]line - run [arg...] -- プログラムのデバッグ実行開始 -- 引数をつけると、それがそのままプログラムに渡される。 - step, s -- 次の行を実行 -- その行に関数が含まれている場合は、関数の中で step 実行する。 - stepi, si -- 次の行を実行 -- 次の行が関数呼び出しである場合、その関数を実行して抜けた直後で止まる。(即ち、その関数の中では止まらない) - next, n -- 次を実行 -- その行に関数が含まれている場合は、関数を全て 1 step で実行する。 - continue -- 次の breakpoint まで実行する。もし次の breakpoint がない場合、プログラムの最後まで実行する。 - print, p <variable> -- プログラム中の変数 <variable> の値を表示する。 - printf <format>, <variable> [,<variable2> [, ...]] -- プログラム内の変数を <format> に従った書式で表示する (gdb) printf "[id:%d][address: %p]\n", i, address_array[i] - list, l -- 現在中断している場所の周辺のプログラムコードを表示する。 -- 表示領域を指定したい場合は、引数に開始行番号と終了行番号を半角コンマで区切って渡す。 (gdb) l <start-line-no>,<end-line-no> - info -- 各種情報の表示 -- info breakpoints: 現在設定されている breakpoint の一覧 -- info locals : ローカル変数の一覧 -- info thread(s) : スレッドの一覧 //=============================================================================== ** break point の保存・読み出し [#x850b805] - save -- save breakpoints <file-name> : 設定した breakpoint を <file-name> に保存する -- save gdb-index -- save tracepoints - source -- save コマンドで保存したファイルを読み込む -- source <file-name> : <file-name> を読み込む。 ///////////////////////////////////////////////////////////////////////////////// * 無反応になったプログラムの状態を調べる [#ra57a878] + 現在の状態を調べるため、現在の状態を core に吐かせて終了させる $ kill -ABRT <PID> または~ $ kill -6 <PID> + 出力された core を解析すると、上記 kill でシグナルを送られたときの状態を確認できる。 ///////////////////////////////////////////////////////////////////////////////// * マルチスレッドプログラムの解析 [#k0c18a6e] - info thread -- スレッドの一覧を表示。core の解析時にも使える -- 現在選択されているスレッドのエントリの左端に "*" が表示される。 - thread <ThreadID> -- 解析したい スレッドを選択する - 選択中のbacktrace (bt), frame, info などのコマンドを普通に使って解析することが出来る。 ///////////////////////////////////////////////////////////////////////////////// * batch 処理 [#yeac6740] - コマンドを自動実行することが出来る。 - core dump の解析である程度使用するコマンドが決まっている場合に使える。 ** 使い方 [#dc2c4c71] + コマンドを記述したテキストファイルを用意する -- 例 $ vi command.gdb info thread thread 2 info locals + core を解析する $ gdb ${PROGRAM_FILE} -c core -batch -x <command-file> + 結果が出力される -- このとき、<command-file> に記述された途中のコマンドでエラーになった場合、それに続くコマンドは実行されることなく、gdb は処理を終了する。 ///////////////////////////////////////////////////////////////////////////////// * フロントエンド [#front-end] //=============================================================================== ** ddd [#ddd] - GUIデバッガ。「gdb を使わなければならないが CUI が苦手」という人にとっては、gdb を直接触るよりも多少マシかも知れない。 //=============================================================================== ** xxgdb [#xxgdb] - GUIデバッガ。 ddd とほぼ同等の機能を有するが、ddd よりは軽量。 //=============================================================================== ** eclipse [#eclipse] - IDE の一種。 - デバッグ実行機能として gdb を使用する。 ///////////////////////////////////////////////////////////////////////////////// * core file [#be3d20b9] - core file が出力されない場合は、 ulimit コマンドでユーザリソースの設定を変更する(bashの場合) - まずは確認 $ ulimit -c 0 - 設定する -- ${HOME}/.bashrc に以下を記述 ulimit -c unlimited -- core のサイズを制限したければ、 "unlimited" の代わりにブロックサイズ値を指定することが出来る。しかしその場合、core の情報がその上限値によって制限され、gdb での debug 時に支障をきたす可能性がある。