怎么回事，半个月没做，刚刚怎么复现不了这条日志了

具体的问题是在一个奇怪的地方 assert 失败了，debug 发现竟然是 build system 的问题，我就觉得事有蹊跷。
现在猜测大概问题是因为 ccache 和 cmake 没有配合好（？）。加上现在某个 python 生成的 C header 文件中的枚举值不太 reproducible，导致不同的 compile unit #include 了不同版本的头文件（？）。都是猜测， dr 的 build system 过于复杂，先不 debug 了，重新编译后暂时正常了。

继续运行 libc 程序，遇到了这样一条指令： mv tp,s0 。因为使用了 tp，所以需要 mangle 这条指令：当前 tp 指向 spill state，而要正确运行的话，应该让 tp 指向 app tls，运行完这条指令后，再把 tp 指回 spill state。

spill state 中有 5 个槽位： a0, a1, a2, a3, tp ，我们会用到 a0 slot 和 tp slot，其中 tp slot 放的是 app tls。

1. 找一个 scratch reg，要求是 scratch reg 不能出现在被 mangle 的指令中。
2. 把 scratch reg 的值存到 spill state a0 slot。
3. 把 tp 的值放到 scratch reg。
4. 通过 scratch reg 把 spill state 中的 tp slot 取出来放到 tp。此时 tp 中的值由 spill state address 变成了 app tls。
5. 运行 mv tp,s0。
6. 通过 scratch reg 把 tp 保存回 spill state tp slot。
7. 把 scratch reg 的值 mv 到 tp。此时 tp 的值变回了 spill state address。
8. 通过 tp 把 spill state a0 slot 加载到 scratch reg 恢复它的值。

> 可见如果 tp 只是 rd 的话，第 4 步是不需要的；如果 tp 只是 rs 的话，第 6 步是不需要的，但这个后面再优化吧

翻译成代码了

在 pc=0x4d792b90 的 basic block 里面直接死循环了

0x427eff1c      beqz    a0,0x427eff40        #1
0x427eff20      sub     a0,a0,a2             #2
0x427eff24      bnez    a0,0x427eff34        #3
0x427eff28      ld      a2,16(tp) # 0x10
0x427eff2c      ld      a0,8(a1)
0x427eff30      jr      a0
0x427eff34      add     a1,a1,16             #4
0x427eff38      ld      a0,0(ra)             #5
0x427eff3c      j       0x427eff1c           #6
0x427eff40      ld      a0,8(a1)
0x427eff44      li      zero,-1
0x427eff48      bnez    a0,0x427eff6c
0x427eff4c      ld      a1,160(tp) # 0xa

死循环的位置，接下来搞清楚这段代码是怎么生成的

好的，定位到位置了，是 emit_indirect_branch_lookup 实现有错，但还没看是哪里。先吃饭吧。

原来是抄 Aarch64 代码的时候，漏掉把 X1 换成 A1 了。

0x427eff34      add     a1,a1,16
0x427eff38      ld      a0,0(ra)

可怕，aarch64 可以在指针里面塞个 Pointer Authentication Code 做加解密，来防止指针被篡改。

哇，带 libc 的 hello world 工作了！！！！

然而动态链接的还有 bug，sad

经常分不清楚 jit 出来的代码是 dr 的还是 app 的。现在有个想法是在所有 dr 代码 emit 的头尾分别放上一个特殊的 nop 来帮助我 debug： addi x0, x0, magic_number ，这样只要看到这个 pattern 的指令，我就立刻可以知道两条 nop 之间包裹的指令序列是哪个 emit 函数生成的。

刚要睡着，突然想到了问题的原因，起床修掉了。太棒了！

过于兴奋睡意全无了现在

划水的时候一直感觉今天还有什么事没做，刚刚终于想起来要在今天结束前交月报

浅玩了一下 wasm。试了在 C 中调用 JavaScript 函数、在 JavaScript 中调用 C 函数、在 JavaScript 中调用 C 函数指针。LLVM 和 wabt 都蛮好用，和 JavaScript 的交互也很符合直觉。

尝试了一下 emscripten，但很快就放弃了，用过感觉人都不干净了。

接上：
目标是想实现一个在浏览器上运行的全系统 RISC-V 模拟器跑 Linux，预期性能要远高于 TinyEMU 才有意义。原本是想基于 TinyEMU 改改，但最终还是决定自己从头实现。
目前调研了和 TinyEMU 相同的单线程执行模型，即模拟器是单核的，然后运行一定周期后，退回到 JavaScript，然后再 setTimeout(run, 0) 重新进入 wasm，避免堵塞 UI。
接下来 --
1. 调研 Service workers，看有没有可能每个 CPU 一个 worker，然后起一个多核系统？
2. 调研在 wasm 中 JIT 的可能性，即在 C 中把 guest 按 basic block 生成 wasm 字节码传给 JavaScript，后者将其动态生成并注册成 wasm 模块，然后通过 indirect call 调用 wasm 模块。
3. 调研是否可以用 IndexedDB 实现文件系统。

似乎可以直接用这个 API 实现一个正经的文件系统？