YamaKen
yamak****@bp*****
2005年 9月 8日 (木) 10:08:30 JST
ヤマケンです。提案ありがとうございます。 At Wed, 07 Sep 2005 23:04:45 +0900, yusuk****@w5***** wrote: > YamaKen wrote: > > だいぶ間が空いてしまいましたが、r1450で対策コードを入れてみまし > > た。SCM_GCC4_READY_GCを1に設定すると有効になりますが、まだ > > uim-scm側の対応コードがないのでsscmで試すだけしかできませんが。 > この仕掛けは大掛かり過ぎな気がするので、考えてみたのですが > インタプリタの出入り口の関数だけは > ローカル変数を詰めた構造体を作って順序を > 保証するというのはどうでしょうか？ > struct { > ScmObj stack_start; > ScmObj str_port; > ScmObj ret; > } local_variables; こういった発想は頭になかったのでおおっと思ったんですが、順序保証 メソッドについては既に問題ではなく、[Anthy-dev 2281]のようなそれ なりに単純な仕組みで自由度の高いコードが書けます。 問題は暗黙のインライン展開です。 [Anthy-dev 2281]のやっている事は基本的に以下のような関数分離です が、この場合eval_strが暗黙に展開されてしまった場合にstr_port等が caller側に展開されてstack_startの範囲外に出てしまう可能性が考え られます。既に保護された状態で呼ばれる事を想定している関数を呼ん だ場合、田畑さん案でも同じ問題が発生します。このインライン展開を 防ぐ事があの大がかりなマクロの目的です(storage-protection.c の Design Considerations参照)。 caller: { ScmObj stack_start; gc_protect_stack(&stack_start); eval_str("(number->string 32)"); gc_unprotect_stack(&stack_start); } static const char *eval_str(const char *exp) { ScmObj str_port = SCM_FALSE; ScmObj ret = SCM_FALSE; str_port = Scm_NewStringPort(exp); ret = SigScm_Read(str_port); ret = EVAL(ret, SCM_NULL); return SCM_STRING_STR(ret); } …と、ここまで書いて気付いたんですが、インライン展開を防ぐ事が目 的なら一旦&eval_strをstorage-protection.oの関数に通してから (*f)(exp)の形で呼ぶようにすれば関数として呼ばれる事が保証できま すね。ちょっとその形に変更してみます。 よい刺激ありがとうございました。 ------------------------------- ヤマケン yamak****@bp*****
