JTAG ICEの改良

今日はSH2用JTAG ICEを改良しています。画面の中の子ウィンドウの位置合わせなど、コマゴマした調整もありますが、ブレークポイントの扱いについて特に改良しています。

現在公開しているSH2用JTAG ICEは、ハードウェアブレークポイントを使用しているため、ブレークポイントが４つまでしか設定できませんでした。

しかし、GDBやInsightからデバッグする際には、数の制限を気にすることなくたくさんブレークポイントを仕掛けたいものです。
そこで、ソフトウェアブレークポイントに対応させることにしました。

GDB上で、ブレークポイントを設定しようとした場合、GDBはスタブに対して「Z」というコマンドを発行します。
「Z」コマンドには、Z0とZ1があって、Z0はソフトウェアブレークポイント、Z1はハードウェアブレークポイントです。現在のJTAG ICEは、「Z」を処理するように作られています。

しかしハードウェアブレークポイントは4つしかないので、５つ目のブレークポイントでZコマンドを拒否すると、GDBはいきなり拒否されておかしな挙動にでてしまうようです。

そこで、JTAG ICEでは、「Z」コマンドを処理しないようにしたら、GDBは「Z」コマンドをあきらめて、メモリ書き込みコマンドを使ってソフトウェアブレークポイントを設定するような挙動に出るようです。

つまり、停止させたい番地に未定義命令（sh-elg-gdbの場合は0xc320）を書き込んで、未定義命令例外を使ってデバッガに制御を移すという方法で、今月のInterface誌に山際伸一さんが書かれている方法を、GDBは使ってきました。

ちなみに、ARMのデバッグの場合、GDBはソフトウェアブレークポイントの実現のため未定義命令（0xe7ffdefe）を書き込んできます。ですから、ARMでJTAGデバッガを作る際には、データバスに0xe7ffdefeが出現したのをEmbedded-ICE RTを使って検出し、命令実行前にトラップさせるとうまくいきます。
ARMの場合では、未定義例外を発生させる前に捉えるのがコツです。

SHのデバッガの場合もどちらかというと、ARMの場合に原理は似ているでしょう。これで、ソフトウェアブレークポイントが実装できました。もう、何個設定しても、ちゃんと動きます。

それから、Insightって安定してないなー、すぐ落ちるなーと思っていたのですが、私が使っていたバージョンが古かったようです。
私が使っていたバージョンは、GDB5.3-GNUWING20030801と書かれていますので、かなり昔のバージョンなのでしょう。

ためしに、山際さんの記事で紹介されているInterfaceのダウンロードページにあるInsightをダウンロードして使ってみたところ、すっごく安定しているじゃないですか。バージョンを見てみると、GDB 6.4.0だそうです。これならかなり快適にデバッグできそうです。