GDB／GDBserverによるクロスターゲットのリモートデバッグ：Programing Bible（3/3 ページ）

[Avi-Rozen，Open Tech Press]

デバッグの実際

　デバッグをするためには、コンパイラ／リンカに-gコマンドラインオプションを指定して、デバッグ情報付きでアプリケーションをコンパイルする必要がある。その結果、生成される実行可能ファイルが大きくなりすぎてターゲットプラットフォームのストレージスペースに入り切らないことがある。その場合は、ファイルを移動する前にpowerpc-7450-linux-gnu-stripでデバッグ情報を取り除き、デバッグ情報除去後のファイルをターゲットプラットフォームに置けばよい。除去後のファイルがターゲットプラットフォームのGDBserverで実行され、除去前のファイルが開発ワークステーションのGDBに読み込まれる。

　リモートデバッグは、特に複雑なところはない。ターゲットプラットフォームで、GDBserverを用いてアプリケーションを起動し、その際、TCP接続からの情報をリスンするホストとポートを指定する。

gdbserver HOST:PORT PROG [ARGS ...]

　続いて開発ワークステーションで、クロスターゲットGDBを起動する。

powerpc-7450-linux-gnu-gdb PROG

　デバッグ情報を取り除く前の実行可能ファイルを指定すること。GDBコンソールで次のように入力する。

target remote HOST:PORT

break main

continue

　これらのコマンドは、GDBをターゲットプラットフォームのGDBserverに接続し、プログラムの先頭にブレークポイントを設定し、最初のブレークポイントに達するまでプログラムを走らせる。

　次のようにすれば、GDBserverを既に動作しているプロセスにアタッチすることもできる。

gdbserver HOST:PORT --attach PID

　その後、プロセスは停止するので、リモートのGDBを用いてデバッグできる。

　GDBのコマンドはリモートアプリケーションをデバッグするときも期待したように動くが、幾つか例外がある。顕著な違いは、runコマンドを使わない点だ。デバッグセッションの開始時にプログラムが既に動いているからだ。また、プログラムを最後まで実行できるようにした場合、プログラムとともにリモートGDBserverも終了し、さらにリモートセッションが終了することも奇異に感ずるだろう。

　実用的なリモートデバッグ環境をセットアップするのは、「結局、printfが一番頼りになる」とのたまうお方には荷が重すぎるかもしれない。しかし、GDBを使えばコードやデータフローの追跡だけでなく修正も可能なので、コード自体に何も手を加えずにコードの挙動を詳しく調べることができる。バグを解決する魔法ではないが、頼りになることは間違いない。

Avi Rozenは、機械視覚を用いた製品を開発する企業の研究開発担当シニアエンジニア。

原文へのリンク