这恰恰表明没人再关心调试奇偶标志了

The Old New Thing (Raymond Chen) 新闻
parity-flag x86-64 windows-debugging bug-fix low-level history

摘要

Windows调试引擎（x86-64）中的一个错误错误地报告了奇偶标志，二十多年来未被发现，凸显出该标志极少被调试。

<p>x86-64架构从x86-32继承了奇偶标志（PF），而x86-32是从8080继承的，8080又是从8008继承的，8008实现它是因为它是Datapoint 2200串行终端的处理器。</p> <p>奇偶标志还有一个次要用途：作为 <code>FXAM</code>（x87）和 <code>UCOMISD</code>（SSE）指令记录浮点比较结果的场所。你仍然可以通过检查某个值是否为NaN或进行浮点相等/不等比较来诱使编译器检查奇偶标志（因为NaN总是无法通过相等和不等比较）。</p> <p>事实证明，Windows调试引擎（x86-64）中有一个错误，它报告奇偶标志时与实际相反。当奇偶标志置位时，它显示的是“po”而不是“pe”，反之亦然。</p> <p>这个错误二十多年来未被报告，说明没人关心调试奇偶标志。</p> <p>已经有一个修复补丁。我们会看到它是否能在本文发布前推送出去。</p> <p>该文章 <a href="https://devblogs.microsoft.com/oldnewthing/20260518-00/?p=112334">这恰恰表明没人再关心调试奇偶标志了</a> 首次出现在 <a href="https://devblogs.microsoft.com/oldnewthing">The Old New Thing</a> 上。</p>
查看原文
查看缓存全文

缓存时间: 2026/05/19 15:34

# 这就说明没人再关心奇偶标志位的调试了 - 《旧事新说》 来源：https://devblogs.microsoft.com/oldnewthing/20260518-00?p=112334 2026年5月18日 ❤️ 点赞 🧠 震惊 4 条回应 x86-64架构从x86-32继承了奇偶标志位（PF），而x86-32又从8080继承而来，8080则源自8008，8008之所以实现该标志位，是因为它是Datapoint 2200串行终端所使用的处理器。 奇偶标志还有一个次要用途：作为`FXAM`（x87）和`UCOMISD`（SSE）等指令记录浮点数比较结果的地方。你仍然可以通过检查某个值是否为NaN（非数），或执行浮点数相等/不等比较（因为NaN在相等比较和不相等比较中永远返回假），来引诱编译器检查奇偶标志位。 结果发现，x86-64的Windows调试引擎存在一个bug：它报告的奇偶标志位与实际情况相反。当奇偶标志置位时，它显示"po"而非"pe"，反之亦然。 这个bug在二十多年间无人报告，这说明没人关心奇偶标志位的调试。 修复代码已经提交。我们看看它能否在本文发布之前上线。 ### 分类 ### 标签 ## 作者 Raymond Chen Raymond参与Windows的演变已有三十多年。2003年，他创办了一个名为"旧事新说"的网站，其受欢迎程度远超他最狂野的想象——这种发展至今仍让他毛骨悚然。该网站催生了一本书，书名也恰好叫《旧事新说》（Addison Wesley 2007）。他偶尔会在Windows Dev Docs的Twitter账号上讲故事，而这些故事并不传达任何有用信息。 ## 下一篇 ## 及时获取更新 当新文章发布时获得通知。 关注此博客 - https://twitter.com/ChenCravat - YouTube (https://www.youtube.com/playlist?list=PLlrxD0HtieHge3_8Dm48C0Ns61I6bHThc) - https://github.com/oldnewthing - https://devblogs.microsoft.com/oldnewthing/feed/

相似文章

Let's Decode the Mystery Bytes [video]

Hacker News Top

本视频通过反汇编和WinDbg调试工具，揭示了在x86环境下calloc分配内存时出现的8个神秘字节实际上是Windows堆管理器的条目头部，包含当前块大小、前一块大小等信息。

精准调试基准：你的模型在调试还是在重写？

Hugging Face Daily Papers

# 论文页面 - 精准调试基准：你的模型在调试还是在重写？ 来源：[https://huggingface.co/papers/2604.17338](https://huggingface.co/papers/2604.17338) ## 摘要 前沿大模型在测试通过率上表现优异，但在调试任务中的精准度却很低，暴露出功能正确与精准定位缺陷之间的鸿沟。与代码补全不同，调试需定位错误并做针对性修改。我们观察到，前沿大模型在调试时往往重写出正确却过度修改的代码。