今天学习了一下 rseq（restartable sequence），想到这个东西在 gdb 中的实现应该和 ll/sc 很像。但搜了一下 gdb 源码，各大架构好像都没有实现？大家对这个东西完全没有调试需求吗？
DR 等 DBT 对信号的处理都相当复杂，其本质原因是 Linux 的信号可以在任意时刻发生，而 DBT 不得不注册一个全局的 signal handler 对所有的信号统一处理再分发来模拟内核行为。
这就要求：
1. DBT 要么时刻保持精确的 guest 状态（和性能不可兼得），要么可以在任意时刻恢复出精确的 guest 状态；
2. trace building、basic block linking 等让执行流尽可能保留在 code cache 的优化手段进一步增加了复杂性 -- 异步信号 interruption point 所在的 basic block 必须 unlink 来保证可控的执行时间；
3. syscall 可能会等待一个信号，所以所有的 pending 信号必须在 syscall 之前被处理；
4. rseq 如果被信号打断，则需要重启；
5. ......
这就要求：
1. DBT 要么时刻保持精确的 guest 状态（和性能不可兼得），要么可以在任意时刻恢复出精确的 guest 状态；
2. trace building、basic block linking 等让执行流尽可能保留在 code cache 的优化手段进一步增加了复杂性 -- 异步信号 interruption point 所在的 basic block 必须 unlink 来保证可控的执行时间；
3. syscall 可能会等待一个信号，所以所有的 pending 信号必须在 syscall 之前被处理；
4. rseq 如果被信号打断，则需要重启；
5. ......
ksco 的工作日志
https://sourceware.org/pipermail/binutils/2023-October/130237.html 第一次给 binutils-gdb 交 patch，也不知道能不能合。🙏
Approved-By: Andrew Burgess
🥰3
GitHub Actions 最近上了一大批 AMD 的 x86 机器，DR 的某几个 x86 测试只要分到这些机器上就大概率会挂，上游又比较缺人修，每次想合代码都要 rerun 好多遍撞大运，好烦啊 😫
详细说明一下 box64 这个 bug 现象：
在运行某些 windows installer 的时候，观测到
这个 bug 非常奇特，box64 常用的 debug 手法得到的全是误导信息，花了好多时间在这些假信息上。
在运行某些 windows installer 的时候，观测到
lock or dword ptr [eax], edx 执行失败，如果在 Dynarec 中禁用这条指令，则一切正常。挂上 gdb 后发现，segv 的地方是 sc.w.aqrl ，这个指令试图去写 0x401000 这个地址， info proc mapping 显示这块内存是 r-x，然后尝试写了几次之后，不知道在什么地方 TF 变成了 1（其实就是在上图中的 signal handler 中，把 x5 的值当成 eflags 了）然后 box64 进到了单步模式（每执行一条指令就会主动进 sighandler，即 SIGTRAP），再然后从 signal handler 回来之后，又跑了一会，从栈上弹了个 0 给了 RIP，然后就炸了。这个 bug 非常奇特，box64 常用的 debug 手法得到的全是误导信息，花了好多时间在这些假信息上。
👍2