- 追加された行はこのように表示されます。
- 削除された行は
このように表示されます。
!XML-RPCでgdbを使う
いろいろなアーキテクチャをテストするための
というか研究のターゲットシミュレータ環境として[MICS|http://www.sgn.ip.titech.ac.jp/miyo/mics/]というのを作り中．
...なのだけど，gdbと連携してCPUの動作をシミュレーションするための
モジュールの作成のデバッグが結構面倒だった．
というのも，MICSは，WindowsのEclipseで書いていて，
対象としている各種アーキテクチャ向けのgdbは，
同じコンピュータのcoLinux環境で動作しているので，
いったりきたりの手間が，なかなか馬鹿にならない．
というわけで，gdbをXML-RPCでラップしてみた．
すると，これがなかなか便利．
{{ref xmlgdb.tar.gz}}
サーバ側で，
java -Dnet.wasamon.xmlgdb.port=8192 \
-cp classes:lib/commons-codec-1.3.jar:lib/xmlrcp-2.0.1.jar \
net.wasamon.xmlgdb.GdbServer
と起動しておいて，クライアントは，たとえば，
java -Dnet.wasamon.xmlgdb.port=8192 \
-cp classes:lib/commons-codec-1.3.jar:lib/xmlrcp-2.0.1.jar \
net.wasamon.xmlgdb.SH3Test a.out
というわけで，gdbをXML-RPCでラップしてみたところ，これがなかなか便利．
XML-RPCのコードでは，
http://ws.apache.org/xmlrpc/xmlrpc2/
を利用しているので，やりとりできる型は，
http://ws.apache.org/xmlrpc/xmlrpc2/types.html
に限定されるけど，適当にラップすればいい話．
byte[]配列は，エンコード/デコードして送受信してくれるので
gdbでデバッグする対象コードをサーバに転送することもできる．
XML-RPCみたいな疎な結合で切ってみると，
関係ないはずのクラス同士が，
意外に密な結合を必要をしているのがあきらかになって
自分の設計の悪さがよくわかる．
...と，作ってみたものの，
コマンド末尾がgdbでない場合とパス内に空白がある場合には，
コマンドを実行しないようにしていたけど，
やっぱり，かなり危険なコマンドだな...
サーバ側ではgdbを実行するために
与えられたパスの子プロセスを生成しているので，
悪意のあるアクセスをされるとかなり危険かも．
一応，コマンド末尾がgdbでない場合とパス内に空白がある場合には，
子プロセスを生成しないようにはしているけど...
と書きながら，かなり危ないことを思いついてしまった．