自分流のデバッグ方法

linux

http://d.hatena.ne.jp/i_ogi/20090423/debughackscon
ビデオを一通り見ました。
GDBについてはさほど詳しく話はなかったけど、デバッグに関する色々な話が聞けておもしろかった。


自分流のデバッグ方法について書けとビデオの中でいっていたので書いてみる。

基本はprintデバッグです。
組み込み開発になるとGDBのような高級なデバッガは使えません。
ブートローダやカーネル起動の初期まではICEが大活躍。
ICEとprintデバッグを何時切り替えるかはシリアルが使えるようになってから。
自分にとしてはICEは便利なんだけどprintデバッグよりははるかに使いにくい。
シリアルさえ使えるようになればこっちのもので、あとはprintデバッグに切り替えられるので見やすくなります。


問題はprintデバッグしか方法が無く、再コンパイルが必要な事。
さらに組み込み系なので実機にプログラムを焼く時間もかかるので時間との勝負なのが辛い。

これを結構やる。

どうやるかというと、
ソースコードとエラーメッセージとバグが発生した状況を頭の中に叩き込む。
エラーメッセージからソースコードのどこで発生したかを突き止めて、そこに至るルートを調べて頭に入れる。
あとはバグが発生した状況だけど、これはバグを発生させた手順とか条件を経験と勘である程度範囲を想定、特定する。
ここで先ほど頭に叩き込んだソースコードと合わせながら辺りをつけてGDBなりprintデバッグなり仕込んでいく。
これでバグが発生するルートを見つけれれば、バグも自然に分かって修正できる。


今思い返すと、自分にとって数学の問題を解く方法が脳内デバッグの原点だったように思う。
具体的に言えば、中1?の式の展開だったと思う。
例えば、(x + 1)(x + 2)を展開する。
学校ではこんな感じで教わるはず。
(x + 1)(x + 2) = x^2 + 2x + x + 2 = x^2 + 3x + 2


始めは確かにこの通り教わって、教わった通りに問題を解いていく。
けど間の部分("x^2 + 2x + x + 2")をいちいちノートに書くのが面倒くさくなる。
これを何とか省略したいと思うようになってくる。


そして、自分はこれをこんな考え方を脳内で行うようになっていった。
上の式を一般化すると (ax + b)(cx + d) のようになる。(a〜dは任意の値)
これを展開すると次のような式に変形できる。
Ax^2 + Bx + C(A〜Cは任意の値)
ここで次のような式が成り立つ。
A = a*b
B = a*d + b*d
C = b*d
つまり、脳内では式全体を考える必要はなく、A、B、Cをそれぞれ単体で計算してやれば良い。
慣れれば最高4乗の計算までなら計算できた。


ただ問題があって、これを行うと他の人が複数行に渡って計算式を書くのに自分は「問題 = 答え」のみの2行の答えとなる。
テストとか黒板にこれをそのまま書くと途中の計算式がないので、先生によっては答えが有っていても間違いにされること。


脳内デバッグはこれと似ていて脳内に必要な部分だけ詰め込んで脳内でプログラムを実行して動きを確かめる。
それを実際のプログラムで確かめて確認作業を行うという流れになる。