call chezscheme from rust

gitでリリースされてる奴は64bit用。それをかまわず32bitなマシンで実行してエラーを楽しむ(変態だな)。

error[E0308]: mismatched types
 --> src/main.rs:7:42
  |
7 |         Sfixnum_value(Scall2(ti, Sfixnum(x), Sfixnum(y)))
  |                                          ^ expected `i32`, found `i64`
  |

どうやら32bit用のchezでは、整数の扱いが32bitみたい。あれ？ 巨大整数にswitchしてくれないのかな。数字に五月蝿いschemeの特徴だと思うんだけど。

sakae@deb:/tmp/chez-sys$ cargo r          
Compiling chez-sys v0.1.0 (/tmp/chez-sys)
error: linking with `cc` failed: exit status: 1                                   |
  = note: "cc" "-m32" "/tmp/chez-sys/target/debug/deps ...
  = note: /usr/bin/ld: /tmp/chez-sys/target/debug/deps/chez_sys-154e0aee2832fb79.3zkps90p5d2qr35f.rcgu.o: in function `chez_sys::myadd':
          /tmp/chez-sys/src/main.rs:6: undefined reference to `Sstring_to_symbol'
  = help: some `extern` functions couldn't be found; some native libraries may need to be installed or have their path specified
  = note: use the `-l` flag to specify native libraries to link
  = note: use the `cargo:rustc-link-lib` directive to specify the native libraries to link with Cargo (see https://doc.rust-lang.org/cargo/reference/build-scripts.html#cargorustc-link-libkindname)

The links field これが関係してくるのかな？ やっぱり、オリジナル版で、雑音が無い環境でやるのがよかろう。

それはいいけど、rust-gdbも余り頼りにならないし、どうしたものか？ use dbg!()

問題は、scheme.boot等がロード出来無いって亊なんで、straceで所要のファイルがオープン出来ているか、確認すればいいな。これ、今回の場合にだけ使えそうな、特殊相対性理論です。どんな場合でも使える、一般相対性理論は、アインシュタインも完成するまでに10年を要しているから、先の亊は考えない。

chez-sys main版に対抗して、C言語版を作っておいたので、それで予備実験 @32bit

sakae@deb:/tmp/t$ strace ./a.out |& grep open
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/i386-linux-gnu/libm.so.6", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
  :
openat(AT_FDCWD, "./petite.boot", O_RDONLY) = 3
openat(AT_FDCWD, "./scheme.boot", O_RDONLY) = 4

うん、相対チェックには、もってこいだな。

いよいよ前回の最後にやった、アプリ版の実行。

sakae@pen:/tmp/chez-sys/target/debug$ strace ./chez-sys |& grep open
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libz.so.1", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libuuid.so.1", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libgcc_s.so.1", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libm.so.6", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libdl.so.2", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/proc/self/maps", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/tmp/t/petite.boot/tmp/t/scheme.boot\nS_generic_invoke return", O_RDONLY) = -1 ENOTDIR (Not a directory)
write(2, "cannot open boot file /tmp/t/pet"..., 83cannot open boot file /tmp/t/petite.boot/tmp/t/scheme.boot

確かに、こんなファイルは無いなと納得。それでいいのか？ どうも、ファイル名を表す文字列の表現に難があるっぽい。鬼門だな。

SDDに負担をかけない様、作業はMEMORY DISKにしてる/tmp上で行っている。作業が済んだら、それをSDDに保管って流れ。そんなルーチンを取っているものだから、main.rsとlib.rsが同居するというcargoの想定外の状況が生れた。

その結果がわけわかめなエラーになった。皆さんもくれぐれも注意しましょう。まあ、cargoが気を効かせて、–libなの？ それとも–binなのって、聞いてきてくれるのが望ましいんだけどね。そこまでは親切ではない。

で、Cの文字列問題を解決して、再び走らせてみると、

sakae@pen:/tmp/chez-sys$ cargo r
    Finished dev [unoptimized + debuginfo] target(s) in 0.01s
     Running `target/debug/chez-sys`
Exception: invalid memory reference.  Some debugging context lost

こんどは、いかにも間口が広いエラーになった。こういう場合はどうする？ もう一歩一歩やるしかないだろう。後ろの方をコメントにして、一つづつ実行範囲を広げていった。

そしたら、最後のprintlnを有効にすると、上記のエラーになる事が確認出来た。それで呼び出している関数を眺めたら、Cの文字列問題が隠れている事を発見。

同じようなミスをしてないか、確認すべきだったね。いわゆる、ゴキブリを一匹見つけたら、他にも十匹は隠れているよって教訓だ。実世界の教訓をソフトウェアの世界にも是非持ち込むべき。

mod bindings;
pub use bindings::*;
use std::ffi::CString;

fn myadd(x: i64, y: i64) -> i64 {
    let ss = CString::new("+").unwrap();
    unsafe {
        let ti = Stop_level_value(Sstring_to_symbol(ss.as_ptr()));
        Sfixnum_value(Scall2(ti, Sfixnum(x), Sfixnum(y)))
    }
}

fn main() {
    let ps = CString::new("/usr/lib/csv9.5.6/a6le/petite.boot").unwrap();
    let ss = CString::new("/usr/lib/csv9.5.6/a6le/scheme.boot").unwrap();
    unsafe {
        Sscheme_init(None);
        Sregister_boot_file(ps.as_ptr());
        Sregister_boot_file(ss.as_ptr());
        Sbuild_heap(std::ptr::null::<i8>(), None);
        println!("{}", myadd(123456, 654321));
    }
}

これが完成図だ。FFIでC言語側とやり取りする場合、文字列はC言語用で用意しなければならない。それが定石のCString::new("xxx").unwrap()て奴。"xxx"は、この時点でrust言語上に文字列だけど、上記を実行すると、C言語用になる。

使う時は、大概文字列のポインターを要求されるので、C言語文字列のインスタンスを引数(って表現でいいのかな？)にして、 as_ptr() を呼び出せばよい。

両者を結合してC言語の関数の引数上で表現する亊も可能らしいけど、種々の問題を孕んでいるので、止めるべきと高名なハッカーがおっしゃっていた。

sakae@pen:/tmp/chez-sys$ cargo r
    Finished dev [unoptimized + debuginfo] target(s) in 0.01s
     Running `target/debug/chez-sys`
777777

実行結果は、あっけないぐらい、つまらないものだ。わざわざ載せるのが憚れられる。

sakae@pen:/tmp/chez-sys/target/debug$ strace ./chez-sys |& grep open
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libz.so.1", O_RDONLY|O_CLOEXEC) = 3
  :
openat(AT_FDCWD, "/usr/lib/csv9.5.6/a6le/petite.boot", O_RDONLY) = 3
openat(AT_FDCWD, "/usr/lib/csv9.5.6/a6le/scheme.boot", O_RDONLY) = 4

一応straceの結果を載せておく。ファイルディスクリプターの３番が開放されていないけど、これって、後で使うからそのままにしてるの？ 変な所に気が付く、困ったちゃんであります。

なお、当初

Sbuild_heap(0 as *const i8, None);

てしてたのを、上記のように普通では思い付かないように書き換えたのは、度々登場してる、家庭教師 clippy君による。binding.rsにも提案が有ったけど、今回は載せないでおく。

上記のように、自助努力で解決したけど、実は二股かけていたんだ。chez-sysの作者さんに、お助けメールをだしてた。ええ、勿論、翻訳ソフトで翻訳させたやつね。

返事がきたので、参考に載せておく。

Hi Sakae,

The chez-sys crate is very low-level, it's the same as interacting directly 
with the C-interface. However, because you're trying to do it via Rust the 
situation actually becomes harder not easier.

The output or your main hints at the answer:

cannot open boot file /tmp/t/petite.boot/tmp/t/scheme.boot

The real problem, though, is that the strings you're giving the C-interface 
are not null-terminated (because Rust strings are not null-terminated). 
The point of `chez-rs` is to provide a high-level interface as well that hides
all these annoying complications, but I have not had time to finish it. 
To that point, I would not recommend you use the crate at all at this time.

Best,
Andrew

>
> Please let me know if you have any hints.

> https://hamesspam.sakura.ne.jp/hes2022/220217.html#org37ea29d

質問はつたない英語より、rust言語で行う方が、確実だ。好き者同士の共通語ですからね。

昔のってか戦前の軍部は、戦争に負けた時の敗因分析をきちんとやらなかったらしい。ただ、精神論で、突撃突撃、勝つまでは我慢我慢ですじゃ、その時点で負けが決定してますよ。

オイラーも多分にこの傾向があるね。

コンパイラーがエラーを捉えて、こうしたらいいよって提案してくれるものだから、顔色を伺って、コンパイルが成功する亊だけを目標にやってきた。

丁度、東大に合格する亊だけが、人生のあがりと思ってる諸君みたいにね(そうじゃ無い志ある諸君がいたらごめんなさい)。親が高学歴だと特にそうだろう。親の言い付けをきちんと守る良い子ちゃんロボット。おっと、言い過ぎたか。

根本原理が分っていなかったんだね。自戒しましょ！！！！

まあ、新たなソースを探検するときは、何をおいてもヘッダーファイルを見ておけってのが、すっかり抜け落ちていた。

kernel.o or libchez.a は、chezschemeのRuntimeになる。いや、最下層の部分。gaucheでは、可搬製を考慮して仮想マシンになってるけど、こちらでは剥き出しの石(amd64とかi386)で動くようになってる。だから速い。

そのマシンに命令を与えるのが、約60個の手続呼出だ。いわゆるシステムコールだな。

Sregister_boot_file の定義場所を探してみる。調べるのはコンパイルの残骸が置いてある場所がよい。ノイズが無いからね。

sakae@pen:/tmp/ChezScheme/a6le/c$ grep Sregister_boot_file *.c
main.c:        Sregister_boot_file(argv[n]);
scheme.c:extern void Sregister_boot_file(name) const char *name; {
scheme.c:  check_boot_file_state("Sregister_boot_file");
scheme.c:extern void Sregister_boot_file_fd(name, fd) const char *name; int fd; {
scheme.c:  check_boot_file_state("Sregister_boot_file_fd");

つらつらとコードを見ていくと、マジック文字列が有るよとかマシンタイプが埋め込まれているとよかが分る。分かり易い例で、

sakae@pen:/tmp/ChezScheme/a6le/boot/a6le$ hd  petite.boot | head -2
00000000  00 00 00 00 63 68 65 7a  49 15 0c 16 28 29 24 80  |....chezI...()$.|
00000010  2a 0b 01 00 4c 09 18 ca  e4 e4 de e4 5a d2 dc ec  |*...L.......Z...|

最初の８文字がマジック。こんなのOS付属のファイルの種別判定には引っ掛らないだろう。謎のフォーマットって亊で、ただのdataとしか表示出来無い(ようにしている)。 それから、１０個のこの種のファイルを読み込めるとか、秘密を暴くって楽しいな。

おっとschemeのコードに出会った時の儀式。consがどうなってるか？ 答はalloc.cに有り。

ptr Scons(car, cdr) ptr car, cdr; {
    ptr tc = get_thread_context();
    ptr p;

    thread_find_room(tc, type_pair, size_pair, p);
    INITCAR(p) = car;
    INITCDR(p) = cdr;
    return p;
}

どうやら、その時のthreadの状況を把握して、そこから必要な場所を確保してるようだ。深入りすると際限がなくなりそうなので、この辺で止めておく。

それからちょっと気になった亊、scheme.hに***LOCKってのがdefineされてる。これが*.cの中で使われていないけど、これって過去の残骸？

Sbuild_heap てのを実行して、初めてヒープが確保されて、登録しておいたbootファイルがロードされるのね。 ユーザー・マニュアルにそう説明されてた。ああ、それでファイル・ディスクリプターをそのまま(ファイルをクローズしない)にしてるんだね。コードを読むと疑問が氷解していくので、気持が好いな。

chezの核心部分は /usr/lib/csv9.5.6/a6le/ 等に出来るけど、いわゆる*.ssはどこにもみえない。困ったものだ。なんたって、scheme.bootみたいなファイルにマシン御で格納されてるからね。どうしても見たいなら、ソースを開く必要がある。

mkheader.ssで、scheme.hを自動作成してた。後はじっくり見ていくしかないだろう。

常々、どうやって*.ssをmake時にコンパイルしてるか疑問だった。じっくりログを眺めてみたぞ。

make all
echo '(reset-handler abort)'\
               :
             '(generate-inspector-information #f)'\
             '(subset-mode (quote system))'\
             '(compile-file "cmacros.ss" "cmacros.so")'\
             | ../bin/i3le/scheme -q
compiling cmacros.ss with output to cmacros.so

chezでコンパイルする時の条件やらをパイプで、出来合いのchezschemeに渡しているね。

*.ssの中で、Sconsとかのkernel側呼出はみつからなかった。どうなってるの？

ちょいと有名な手続をみてみる。例えば、これ。 5_2.ss

(define-who reverse
  (lambda (ls)
    ($list-length ls who)
    (do ([ls ls (cdr ls)] [a '() (cons (car ls) a)])
        ((null? ls) a))))

普通のconsで、何の変哲もない。内心はSconsとかを期待してたんだけど。はて、困ったぞと。

得意のマクロを使ってマシン語を作る時に、変換してるのかなあ(淡い想像だけど)。

こうなったらgdb君の登場かな？

冒頭であげた32bitで動かない問題。無理するなって亊で、

fn myadd(x: i32, y: i32) -> i32 {
    let ss = CString::new("+").unwrap();

こんな修整を施したら、動いた。但し、bindings.rsは、相変わらず64Bit用のリナックスなんで、凝った亊をすると牙を矛く亊でしょう。原理が分っていれば、やみくもの怖がる亊は無い。

SECD Machine

RustでLispインタープリター

This year's Index

Home