VS编译器优化诱发一个的Bug

今天在编译Release的一个动态库的时候，发现release执行异常，然后看到了这篇文章，转载一下，这种情况需要关闭编译器的优化 

项目->属性->C/C++->常规->优化 选择禁止即可。

Bug的背景

我正在把某个C++下的驱动程序移植到C下,前几天发生了一个比较诡异的问题。

驱动程序有一个bug,但是这个bug只能 Win32 Release 版本下的驱动才能重现。在 Win32 Debug 版本下，和 Win64 Release/Debug 版本下均无法重新。

随着一步步的分析，最终发现问题是由于VS编译器的一个优化诱发的。当然这并不是VS编译器的bug,只是由于优化诱发程序里面的某个bug.

调试的思路

1. Debug Vs Release

首先想到的自然是看看Debug版本和Release版本运行是有啥区别了。Release版本本质上和Debug版本没啥区别，一样都可以使用调试器调试，只不过有些大大小小需要注意的地方罢了。基本上熟知编译器的优化原理和调试器，调试Release版本的程序也不是啥困难的事情。

一般导致Debug和Release不同的常见问题无非下面这些，未初始化的局部变量，程序指针访问越界，多线程同步问题。而这些问题都是很容易发现的，但随着调试的深入，并没有发现这些问题的踪迹，反而所有的代码都工作的很好，没啥异常发生。对比Debug和Release版本下的流程，Release版本的问题在于在某个时候硬件没有如期的触发中断。但在这之前两个版本所执行的代码逻辑完全一样，没有啥区别。

问题越发诡异了。

2. 32bit Vs 64 bit

既然64bit Release的版本没有问题，但32bit Release有问题，这也是一个突破的思路。

把相关的代码拿出来仔细梳理，注意看一些32/64bit下的常见问题，诸如指针大小，整数溢出等问题。不过依然没有发现问题。

3. 编译器的优化

Debug和Release的最大的区别自然是编译器的优化不同，但是哪个编译器不是久经考验，要是说编译器上出问题，那真是撞了大运了，所以没有第一时间考虑是由于优化造成的。不过既然直接调试代码没发现问题的所在，那只有使用另外一种分析方法了，那就是不断缩小导致问题的范围。

既然我手上有两个版本，一个好的，一个坏的。那只要不断缩小两个版本之间的不同，最终就能定位到导致问题的部分。

所以第一个拿来开刀的自然是编译器的优化选项。几经尝试，终于发现诱发问题的编译器优化是这一项,Favor Size Or Speed. 诡异，真是相当的诡异呀。不过无所谓，既然找到了这一个线索，下面就好找了。这个优化只是一个函数内的局部优化，只要针对不同的函数分别打开和关闭这个优化，自然就能发现问题所在了。

问题的根源

针对一些可疑的代码，分别打开和关闭这个Favor Size Or Speed的优化，不断的缩小范围之后，最终定位到某个函数是罪魁祸首。然后比较了一下生成的汇编代码，最后定位到了下面这行语句

pDevice->pReg->S = 0xFFFFFFFF;

而这行代码生成的汇编代码如下:

or      dword ptr [eax+10h],0FFFFFFFFh   //Release版本，Favor Size优化
mov     dword ptr [eax+10h],0FFFFFFFFh   //Debug版本，无优化

乍一看一定会觉得这个诡异，因为or和mov指令在这里的逻辑其实是一模一样的，编译器没有任何错误。那为何会有不同的执行效果呢?

其实原因在于pDevice->pReg->S并不是一个普通的内存地址，他是一个MMIO(memory mapped IO) address地址。也就是说这个变量并不存在于内存里面，而是硬件的某个寄存器，只不过和内存共用了一个地址空间。而对于这种MMIO address，虽然可以直接象访问普通内存一样读写他们，但最安全的方式还是使用Windows提供的函数，所以对于这个bug的修复是

WRITE_REGISTER_ULONG(&pDevice->pReg->S,0xFFFFFFFF);

至于为啥会出这种乌龙，其实就是一开始移植的时候粗心大意了。pDevice->pReg->S = 0xFFFFFFFF; 这句C++语句中的=其实一个重载过的C++运算符，内部的实现就是WRITE_REGISTER_ULONG，移植过来的时候也没有细看具体哪个S是个什么东西，就抄过来了