雑記

トラバできてた .so からロード && スケルトンをスクリプトで生成なアプローチのもの (http://nikki.hio.jp/?date=20051124#p01) をながめつつ。

結局どっから情報を持ってくるかって、いう話で、最悪の場合は、人間が手動でテスト登録ルーチンを書くことになるわけ。それよりマシなアプローチとして私が今まで取ってきた方法としては、

などと結局テストコードを生成する方向性なわけだけど、別にその方向性は悪くないんじゃないかとか。例えば LangScan でソース全部なめて、 hoge_test_* という関数定義を抜き出しつつ main を全て排除。抜き出してきた hoge_test_* を全て実行する main を定義してコンパイル→実行、とか。ただこれだと結局本番コードと違うものをコンパイルしなきゃいけないのが少し面倒か。あとテストのためにヘッダを増やすのですらめんどい。でもポータブルだし、安全。でも萌えない。

ソース→オブジェクト→実行ファイル、で見ると上記はソースに手を加える。オブジェクト以降を考えると、自前の crt*.o と ldscript を用意して main 完全無視でほげほげーっていうのもアリかと思った。再配置を自分で実装しなくて良いのがメリット。ただちょっとお手軽さにダメージが。

あとそれより後、 .o ファイル見るんじゃなくて実行ファイル見るっていうのも手か。再配置の時間はだいぶ減るし。ついでに .so 内のテストも実行できるようにしよう。これはすぐ実装できそうだし dtr に取り込んじゃおう。メリットは core が読めることと、 dtr のバグを踏みにくいことか。

追記: 実行ファイルの段階では不要なシンボルは消えてるからダメですね…

で、とか考えてると結局実行ファイル==ダイナミックリンクライブラリな Java はエラいとか頭をよぎって良くない。 Java みたいに VM は無くていいからランタイムシステムがもうちょっと情報出してくれれば…と考えると結局 Objective-C に。

Objective-CGNUStep より小さい標準ライブラリがあると嬉しいんだけど。

追記: 話それすぎ。最初の言及元見て思ったのはテストと言えば統計だ、ということだった。つまりあれです、テストが終わったら

総ステップ数:  12345
OP   TIMES  CLOCKS
mov   2345     ...
jmp   1234     ...
...

とか出るわけだ。ていうか gcov でいいか。

そういえば gcov も専用コンパイルオプションつけなくても実装できる気がするんだけどパフォーマンスの問題かな。

なにかあれば下記メールアドレスへ。
shinichiro.hamaji _at_ gmail.com
shinichiro.h