三次元限定でデバッガを語ろう
タイトルは釣り＞＜
Debug hacks conferenceにもいけず、Debug hacks自体も入手出来ず、流れは読んでませんがそれはデバッガ関係無いですよねに反応。
僕にとってデバッガってのはICEとセットで使う物で、三次元のイメージなんですよね。
参考画像：ICE画像(微エロ)
JTAG ICEが一般的になる前は、ICEってのは測定器と一緒で貴重な物でした。ICE専用に別基板を起こしたり、剣山の上にCPUを乗せてちょっとでも斜め向くと動かないくせにケーブルが重いとか。電源の投入順序で電気的に壊れたりしました。今はJTAG＋メモリ読み出し用のコネクタ程度で済むので良い時代になりました。
そんな僕はデバッガやコンパイラに手をいれるなんてとんでもないと思っているので、デバッガに手を入れていくというのに驚きました。この手の開発環境側に手を入れるのはリスクが大きくて、まあ仕事ではやらない。リスクが大きいってのは「手を入れた影響が把握できないから」につきる。デバッガ、コンパイラに比べるとRTOSをいじるのは抵抗が少ない。例えば、割り込みハンドラをフックして何か処理入れるとか、割り込みから戻る時にどこかに履歴を残すとかは大丈夫。結局の所、こういう事をしても他の所への影響は少ない事を、僕が判断できるからだと思う。
一般的にどこに手を入れたら他への影響が少ないのかって事を考えると、出力だけなら影響ないでしょって事でprintfデバッグに繋がる。非同期な処理が絡むとprintfってのは時間的なコストが大きいので、別のやり方を考えた方が良くって、その話はWin32マルチスレッドプログラミングに書いてあった気がする。
組み込み機器ってのは電源落とすまで基本的には無限ループに入っているのでデバッガが使いにくい状況がでてくる。ブレークかけるとWDTが働いてリセットかかっちゃうとか、通信系の受信バッファがあふれた結果相手側がエラーを検知して落としに来るとか、デバッガの手の届かない範囲で、CPUが止まったらエラー通知してシステム落とせ！って状況がある。この場合は、どうせ落ちるのならブレークかけたいところでめいっぱい情報を残して、自分から落ちた方が良かったりする。でも、最近のデバッガは割り込みの処理だけはしてくれるブレークがあるらしい。素晴らしい。
逆にデバッガにしか出来ない事ってのももちろんあって、一番使うのが異常な状況を作り出すこと。「仕様としてはありえないんだけど、ここに不正なデータがあったらこういう動きするよね」って状況で問題を切り分けたい。前段の処理でエラーチェックしているから不正なデータを渡せない、今の動いているプログラムは手を入れたくない、となるとデバッガで無理矢理そういう状況を作るしかない。デバッガ様々です。
組み込みのデバッグ手法って、人から人へのイメージがあるから、組み込み用ICE/デバッガの使いこなし的な本は欲しい。デバッガの各機能がどういう仕組みで動いているのかの解説書も欲しいと思う。「アドレスXXXXにn回アクセスしたときのブレーク」ってのは、アクセスの感知はどういう仕組みになっていて、n回のカウントはどこの保持してあって、ブレークはどうやってかけているのか、は説明欲しい。
例えばROM ICEだとブレーク時にNMIを使う物がある。基板にロジアナを繋いでNMIでトリガーをかけると、ブレーク前後の基板情報が取れる。こういうのもデバッガの拡張に入るのかもしれない。こういうのができるかどうかってのは、やっぱり仕組みがわかっているかどうかに行き着く。
今のJTAGデバッガだとどういう拡張ができるんだろう。
JTAGデバッガだけじゃなくて、本当のバウンダリースキャンや、FPGAのコンフィグ系まで含めてJTAG HACKSなら一冊分のネタが集まる気がする。
Recent Comments