とりあえずネイティブの処理系に移る前に、wasm2cの出力をEmscriptenでコンパイルする形で動かすのが良いのではないか説。いやまぁwasm2cの出力自体がsignalに依存していたり色々あるわけだけど。。

Emscriptenのsetjmp/longjmpで動かなければ自前の実装で動くはずがない
コンソールとか通信回りのようなフレームワーク部分はこの状態でも開発可能

okuoku

何もしない通信まわりを追加

とりあえず何もしないものを追加。これを更にforkしてlocalhostオンリーの通信機能を追加するのが良いかな。...つまりminiioを使ったtelnetクライアントを用意しないといけないのか。。まぁそれは後で良いけど。

okuoku

とりあえずビルド通す

とりあえず初期化は終わるが、ここで型ミスマッチでクラッシュする。

okuoku

`thr_trampoline` の型を見る会

一旦Emscripten版ではなくネイティブ版で確認していく。

1122            ret = f(my_linux, objtbl[objid].obj.thr.arg32);
(gdb) p f
$1 = (funcptr) 0x1012d436a <w2c_kernel_lkl_run_kernel>

これは戻り型が void だな。。

これも void 。

一旦 void に統一するのが良いかな。。というか良く見たら元々LKLのスレッドは void だった。

TimerとThreadにこの問題があったので修正しておいた。

okuoku

Case sensitive filesystem上だとEmscriptenが動かない

Python path configuration:
  PYTHONHOME = (not set)
  PYTHONPATH = (not set)
  program name = 'D:\wasmlinux\emsdk\python\3.9.2-nuget_64bit\python.exe'
  isolated = 0
  environment = 0
  user site = 1
  import site = 1
  sys._base_executable = 'D:\\wasmlinux\\emsdk\\python\\3.9.2-nuget_64bit\\python.exe'
  sys.base_prefix = ''
  sys.base_exec_prefix = ''
  sys.platlibdir = 'lib'
  sys.executable = 'D:\\wasmlinux\\emsdk\\python\\3.9.2-nuget_64bit\\python.exe'
  sys.prefix = ''
  sys.exec_prefix = ''
  sys.path = [
    'D:\\wasmlinux\\emsdk\\python\\3.9.2-nuget_64bit\\python39.zip',
    '.\\DLLs',
    '.\\lib',
    'D:\\wasmlinux\\emsdk\\python\\3.9.2-nuget_64bit',
  ]
Fatal Python error: init_fs_encoding: failed to get the Python codec of the filesystem encoding
Python runtime state: core initialized
ModuleNotFoundError: No module named 'encodings'

これは罠すぎる。。 sys.platlibdir = 'lib' ではなく sys.platlibdir = 'Lib' が正しい。とりあえず手元ではディレクトリの方を小文字にリネーム(Lib → lib)した。

okuoku

ビルドにとんでもなくメモリを喰う

これHTML側はダミーで開発しないとキツいもんがあるな。。

okuoku

backtraceが激烈におかしい

host_thread_self の機能番号は 2:5 なのに、memorymgr 3:* に飛ぶのはおかしい。。

ここは仕方ないのでprintfデバッグ。。

機能番号は <モジュール番号>:<機能番号> の構成になっているが、機能番号にゼロや異常値が渡っている。こういう事態を想定して、機能番号にはゼロ番が使われないように設計しているので、何か間違ったことが起きていることはわかる。

... いちばん有り得そうなのは thread_local の実装が怪しいとかだろうか。。

okuoku

ときどきメモリオフセットが変わっている

とりあえずdebug printをもうちょっと詳細にする:

diff --git a/hostrunner/runner.cpp b/hostrunner/runner.cpp
index 8e8dd25..118c0f0 100644
--- a/hostrunner/runner.cpp
+++ b/hostrunner/runner.cpp
@@ -1917,7 +1917,7 @@ w2c_env_nccc_call64(struct w2c_env* env, u32 inptr, u32 outptr){

     mod = in[0];
     func = in[1];
-    //printf("CALL: %ld %ld \n", mod, func);
+    printf("CALL: [%lld %lld] (thr %p base %p) %d+%d \n", mod, func, my_linux, mem->data, inptr, outptr);

     switch(mod){
         case 0: /* Admin */

CALL: [2 5] (thr 0x866d730 base 0x2ed728) 137887472+137887464 
CALL: [2 6] (thr 0x866d730 base 0x2ed728) 137887440+137887432 
CALL: [1 8] (thr 0x866d730 base 0x2ed728) 137887456+0 
CALL: [1 4] (thr 0x2ed728 base 0x86817b0) 138542816+0 
CALL: [1 4] (thr 0x3017a8 base 0x10aa17b8) 139198176+0

RunnerではWasm側のポインタとホスト側のポインタのオフセットが一定であることを期待しているが、そうなっていないようだ。

これはwasm2c側の wasm_rt_grow_memory を呼んでいるのがたぶん不味くて、

WASM_RT_USE_MMAP でない場合には普通に realloc を使ってくるため不味い。これは wasm_rt_grow_memory を呼ばなくするしか対策は無いかな。。

okuoku

動いた

なんかめっちゃ遅いけど、これはスレッドの起動にそれなりに時間が掛かるからかな。。

何もしない通信まわりを追加

とりあえずビルド通す

thr_trampoline の型を見る会

Case sensitive filesystem上だとEmscriptenが動かない

ビルドにとんでもなくメモリを喰う

backtraceが激烈におかしい

ときどきメモリオフセットが変わっている

動いた

`thr_trampoline` の型を見る会