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
2019 年微软在编译器层面针对 Prism TSO 模拟性能引入了一项优化
简单说就是，编译器在编译时，是清楚程序中哪些部分需要 TSO 保证的，开启
volatileMetadata ，我觉得非常有创造性：https://learn.microsoft.com/en-us/cpp/build/reference/volatile?view=msvc-170简单说就是，编译器在编译时，是清楚程序中哪些部分需要 TSO 保证的，开启
/volatileMetadata 选项后，这些需要保证 TSO 语义的地址段会被记录到 PE 文件中，然后 Prism 就可以读取这个信息，针对性的做 TSO 模拟，从而避免不必要的性能损耗。Docs
/volatileMetadata (Generate metadata on volatile memory accesses)
Learn more about: /volatileMetadata
👍2
书接上回，给 Box64 加了个迷你 PE parser 来解析并用上了 volatileMetadata，可惜好像没啥游戏有这个元数据（M$ 的号召力太差了