JTAGデバッガとInsight/GDB

引き続きJTAG ICE(デバッガ)を開発しています。

開発中の新しいJTAG ICEは、様々なアーキテクチャのCPUを統一の取れたGUI環境からデバッグすることができることを目指したソフトウェアです。このソフトウェアは各種CPU用のアルゴリズムとGUIの部分が独立しているため、アルゴリズムをとりかえれば別のCPUでもそのまま動作するという仕組みです。

今日は、GDBとの接続ルーチン(GDBSTUB)を作成しました。GDBからTCP/IP経由でこのデバッガにコマンドを送ると、このデバッガの中ではGDBプロトコルを解釈して各種CPUのJTAGのプロトコルに翻訳するルーチンが動き、ターゲットボードを操作することができます。

GDBとInsightは同じようなものだと思っていたのですが、実際に動かしてみると、GDBとInsightで微妙に動作が違う点がありました。Insightは、プログラムをロードした後に、デフォルトでは自動でブレークポイントを設定するので、JTAG　ICEがブレークポイントに対応していなければうまく動作しません。また、普通のCPUに内蔵されているハードウェアブレークポイントは１個から４個くらいまでなので、数が限られています。
ハードウェアブレークポイントだけだと、ARMの場合には2箇所までしかブレークポイントを設置できないなんていう悲しいことになります。常にその数に注意しなければならないのでは、デバッグに集中できません。
気軽にブレークポイントを設置できるようにするためには、ソフトウェアブレークポイントにも対応させないといけません。

ARMの場合、ソフトウェアブレークポイントは、止めたいアドレス上に未定義命令を置くことで実現されます。
未定義命令を実行すると、例外にジャンプしてしまいますが、普通のROMモニタ型のGDBSTUBでは、ジャンプした先の例外ルーチンを使ってGDBとやりとりします。
一方、JTAGデバッガではふつうは例外ルーチンにジャンプしません。命令フェッチの際に未定義命令がデータバスに出現したのを検出して、例外ルーチンへ飛ぶ前にCPUを停止させるというのが正解になります。
※要するにアドレス一致ブレークではなく、データ一致ブレークを使う。
しかしこのような技巧が使えないCPUもありますので、悩ましいところです。

また、GDBには命令キャッシュやオペラントキャッシュの有効無効を指定するコマンドがないようです。あまり考えずに作ったら、GDBからプログラムをダウンロードしても古いキャッシュのままCPUが動作するなんていうこともおきました。でも、これは何とか解決できました。

それから、
　for(i=0;i<1000000;i++) { }
なんていう箇所を、GDBからステップ実行させたら、大変です。
GDBは、次のアドレスまでステップ実行でなんとかしようとしますし、GDBSTUBは受け取ったコマンドを忠実に実行するだけです。
100万回のステップ実行コマンド「s」を発行してくれます。もう止められません。
これはGDBが悪いのでもなく、JTAG-GDBSTUBが悪いのでもありません。
たぶん仕様だと思われます。

そんな感じで動作もだいぶん安定してきました。そろそろお客様からご要望の多かったARM9への対応もはじめようかと思います。