博士

やあ、ロボ子！今日のニュースはJPDB、プレシリコンCPUのデバッガじゃ。

ロボ子

プレシリコンCPUのデバッガですか？それは初めて聞きました。具体的にどんなことができるんですか？

博士

ふむ、JPDBはGDBに触発されただけあって、コードのステップ実行、ブレークポイントの追加、波形値の確認ができるのじゃ！

ロボ子

波形値の確認ですか。それは便利そうですね。使用するには何が必要なんですか？

博士

波形データ、波形内の信号を変換するPythonマッピングファイル、そして実行されるELFファイルが必要じゃ。

ロボ子

Pythonマッピングファイル…少し難しそうですね。

博士

心配ご無用！マッピングファイルは、JPDBの内部GDBサーバスタブが信号を理解できるようにするための変換レイヤじゃ。Pythonの辞書を返す`get_gdb_signals`という関数が含まれていれば良いのじゃ。

ロボ子

`pc`（現在のretired PCの信号）と`x0-x31`（各アーキテクチャ汎用レジスタの信号）のキーが含まれている必要があるんですね。

博士

そうじゃ！それと、Surfer機能を使うなら、Surferがインストールされていて、$PATH上にある必要があるぞ。WCPサポートも必要じゃ。

ロボ子

Surferとの連携もできるんですね。インストール方法はどうなっていますか？

博士

`cargo install --git https://github.com/1024bees/dang jpdb`でインストールできるぞ。

ロボ子

Cargo経由なんですね。ところで、JPDBは具体的にどのような構成になっているんですか？

博士

JPDBは、dang（プレシリコンCPU用GDBサーバ）、shucks（GDBクライアント）、TUIで構成されているのじゃ。

ロボ子

なるほど、それぞれの役割があるんですね。プレシリコンCPUのデバッグは、通常のソフトウェアデバッグと比べて、どのような点が難しいのでしょうか？

博士

プレシリコンじゃから、実機がないのじゃ！エミュレータやシミュレータを使うことになるからの。JPDBは、そういった環境でのデバッグを支援してくれるのじゃ。

ロボ子

エミュレータやシミュレータ上でのデバッグですか。実機がない分、より詳細な情報が必要になりそうですね。

博士

その通り！波形データとか、レジスタの値とか、あらゆる情報を駆使してバグを探すのじゃ！まるで宝探しみたいじゃな！

ロボ子

宝探しですか。なんだかワクワクしてきました！

博士

じゃろ？ところでロボ子、JPDBを使ってデバッグするCPUは何じゃ？

ロボ子

えっと…プレシリコンCPU、ですよね？

博士

ぶっぶー！正解は…まだシリコンになる前のCPUじゃった！