我发现 M2 MBA 开 Telegram 会议，对方分享了屏幕，这时候我切到别的 App 滚动屏幕（比如浏览网页）会有拖影和掉帧，但此时 CPU/GPU 占用并不高，难以理解。
ksco 的工作日志
啊我终于修好了所有已知的 bug，现在又撞到 ASSERT_NOT_IMPLEMENTED 了
怎么回事，半个月没做，刚刚怎么复现不了这条日志了
ksco 的工作日志
怎么回事，半个月没做，刚刚怎么复现不了这条日志了
具体的问题是在一个奇怪的地方 assert 失败了，debug 发现竟然是 build system 的问题，我就觉得事有蹊跷。
现在猜测大概问题是因为 ccache 和 cmake 没有配合好（？）。加上现在某个 python 生成的 C header 文件中的枚举值不太 reproducible，导致不同的 compile unit #include 了不同版本的头文件（？）。都是猜测， dr 的 build system 过于复杂，先不 debug 了，重新编译后暂时正常了。
现在猜测大概问题是因为 ccache 和 cmake 没有配合好（？）。加上现在某个 python 生成的 C header 文件中的枚举值不太 reproducible，导致不同的 compile unit #include 了不同版本的头文件（？）。都是猜测， dr 的 build system 过于复杂，先不 debug 了，重新编译后暂时正常了。
继续运行 libc 程序，遇到了这样一条指令：
spill state 中有 5 个槽位：
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 步是不需要的，但这个后面再优化吧
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 步是不需要的，但这个后面再优化吧
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
死循环的位置，接下来搞清楚这段代码是怎么生成的
ksco 的工作日志
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…
原来是抄 Aarch64 代码的时候，漏掉把 X1 换成 A1 了。
0x427eff34 add a1,a1,16
0x427eff38 ld a0,0(ra)
❤1
经常分不清楚 jit 出来的代码是 dr 的还是 app 的。现在有个想法是在所有 dr 代码 emit 的头尾分别放上一个特殊的 nop 来帮助我 debug：
addi x0, x0, magic_number ，这样只要看到这个 pattern 的指令，我就立刻可以知道两条 nop 之间包裹的指令序列是哪个 emit 函数生成的。❤1