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

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/

相似文章

调试器的谎言

Hacker News Top

作者讨论了在调试Nordic的nRF54L系列时遇到的意外内存值问题，解释了调试器与内部SoC组件的交互如何可能导致此类问题。

核心转储流行病学：修复一个18年的旧bug

OpenAI Blog

OpenAI工程师详细描述了Rockset的C++数据基础设施中看似不可能的崩溃的诊断过程，揭示了一个Azure上的静默硬件损坏bug以及GNU libunwind中存在18年的竞态条件，最终通过崩溃数据的流行病学分析得以解决。