デバッグの実際
デバッグをするためには、コンパイラ/リンカに-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は、機械視覚を用いた製品を開発する企業の研究開発担当シニアエンジニア。