另外我发现 gdbjit 作为一个理应架构无关的东西，在 AArch64 上是好的，但是在 RISC-V 和龙架构上都是炸的。
这两天陷入到了 gdb 的代码中一直找不到原因，直到今天决定在 AArch64 上构建一个 latest gdb 来对比一下执行流，然后就发现是新版本 gdb 的 regression ...
这两天陷入到了 gdb 的代码中一直找不到原因，直到今天决定在 AArch64 上构建一个 latest gdb 来对比一下执行流，然后就发现是新版本 gdb 的 regression ...
gdb 灵车调试小技巧
debuggee 的某块内存在不知道什么地方被写穿了？此时常用的调试方式是使用
这种情况下，一个
感觉应该可以写个 Python 脚本来实现一个全自动的
debuggee 的某块内存在不知道什么地方被写穿了？此时常用的调试方式是使用
watch 命令找到这块内存到底是在哪里被写穿的。然而当 gdb 甚至硬件不支持 hardware breakpoint 时， watch 命令会被以纯软件的方式实现，性能太差几乎是不可用的。这种情况下，一个
watch 的高性能平替是：在内存被写穿之前，使用 call mprotect(addr, size, 1) 将这块内存所在的页设置为只读，这样就可以快速地知道整个页在什么地方被写入了。如果被写入的地方不是感兴趣的区域，则可以用 call mprotect 将内存页改回可写，跳过这个点后，再次改回只读。感觉应该可以写个 Python 脚本来实现一个全自动的
custom-watch ，但我的问题已经解决了，懒得实验了。👍7
炒点冷饭
Mesa 的 x86 libd3dadapter9.so 遵从的是 Windows calling convention，这很合理，因为这个库能且仅能被 wine 调用，直接用 Windows CC 可以省很多事。
但抽象的是这个库也有 RISCs build，而这些架构下并不存在 Windows CC，所以遵从的其实是 SysV CC。初看觉得毫无意义，但 Mesa 的一位开发者给 Box86/Box64 提交了这个库的 wrapping 代码，在这一层把 x86 Windows CC 调用转换成 RISCs SysV CC 调用，因此 Box64 可以正常使用该库。
Mesa 的 x86 libd3dadapter9.so 遵从的是 Windows calling convention，这很合理，因为这个库能且仅能被 wine 调用，直接用 Windows CC 可以省很多事。
但抽象的是这个库也有 RISCs build，而这些架构下并不存在 Windows CC，所以遵从的其实是 SysV CC。初看觉得毫无意义，但 Mesa 的一位开发者给 Box86/Box64 提交了这个库的 wrapping 代码，在这一层把 x86 Windows CC 调用转换成 RISCs SysV CC 调用，因此 Box64 可以正常使用该库。
🤯10