/Gw 链接开关可以告诉链接器优化代码中的全局数据,从而减小最终生成的二进制文件的大小。在 Visual Studio 17.5 预览版2中,我们新增了一个新的标志:/Zc:checkGwOdr[-] ,目的是在使用 /Gw 开关的时候改进对 C++ 标准的一致性支持。
在之前的版本中,当使用 /Gw 开关的时候,某些单定义规则(ODR)冲突会被忽略,并且不会导致错误。有了这个新标志之后,如果发生这种情况的时候,VS 将会报告错误。如果你正在使用 /Gw,则我们推荐使用 /Zc:checkGwOdr 这个标志。默认情况下,这个标志是被关闭的。在将来的新版本 VS 中,我们可以改变这个默认设置。
如果你想了解关于ODR的解释,/Gw 开关,以及有关这个问题的更多信息,请继续阅读。
让我们来看看下面三个定义,先建立对这个问题的基本背景知识:
1. 首先是 COMDAT,简短的描述是 COMDAT 是可以放置数据的额外段,以使链接器能够潜在地从二进制文件中折叠出所述数据。重要的是,这些部分标有如何处理重复项的策略。有关 COMDAT 历史的更深入探讨,请参阅 Raymond 的博客文章,其中涵盖了它们的使用和历史。
2. 接下来,/Gw 开关是做什么的?该开关使编译器能够将全局数据放入 COMDAT 中。这使我们能够优化未引用的全局变量,或通过它们的 COMDAT 部分合并相同的全局变量。
3. 关于单定义规则(ODR),可以在网上找找相关的信息。
有了上面的背景知识,下面我们来看一个简单的例子:
如果不使用 /Gw 开关,编译上面的代码会产生如下的编译错误:
由于我们在 odr.h 中定义了 MyGlobal,因此我们最终在 foo.obj 和 bar.obj 中都有一个定义,导致链接器报告 ODR 违规。现在,如果我们使用 /Gw 编译:
我们最终没有出现错误,那么发生了什么?它最终回到上面提到的 COMDAT 标志。查看 obj 的头文件,我们可以看到 MyGlobal 确实被放置在 COMDAT 中:
这没有显示的是这个COMODAT已被标记为PICKANY。因此,当找到多个可以合并的候选定义时,链接器会任意选择其中一个并丢弃其余定义。不过这很奇怪,当启用 /Gw 时,此 COMDAT 在创建时被标记为 NOMATCH。NOMATCH,顾名思义,意味着如果找到重复项,链接器应该引发错误,这正是我们想要的。那么,出了什么问题呢?
这里的关键是MyGlobal的定义包括零赋值。这会导致另一个优化启动。由于此全局初始化为零,我们注意到它可以移动到 .bss 部分。由于如果此全局数据位于 .bss 中,则不必存储此全局数据,因此移动 COMDAT 可以减小对象文件大小。不幸的是,当我们移动COMCTAT时,标志从NOMATCH重置为PICKANY,导致我们的错误。
从 17.5 预览版 2 开始,你现在可以使用新标志来确保不会在意外使用 /Gw 时隐藏这些 ODR 违规:
暴露错误后,我们可以在头文件中创建全局 extern,并将定义移动到其中一个 cpp 文件以解决问题:
或者,对于 C++17 及更高版本,可以在定义上使用内联说明符 (inline specifier) 。
通常修复 ODR 违规看起来像这样,尽管并非每种情况都如此简单。如果你使用的是 /Gw,我们鼓励使用 /Zc:checkGwOdr,以防止这些冲突蔓延到你的构建中。由于这是一个标准一致性问题,我们可能会在未来的版本中更改 /Gw 的默认行为以暗示 /Zc:checkGwOdr。
总结
不知道你有什么想法,但我感觉这事儿有点按下葫芦 (/Gw) 浮起瓢 (/Zc:checkGwOdr)。
顺便说一句,Topomel Box 开发中,我压根没用过这些高级优化的劳什子玩意儿。
随它去吧。
最后
Microsoft Visual C++团队的博客是我非常喜欢的博客之一,里面有很多关于Visual C++的知识和最新开发进展。大浪淘沙,如果你对Visual C++这门古老的技术还是那么感兴趣,则可以经常去他们那(或者我这)逛逛。
本文来自:《Standards conformance improvements to /Gw in Visual Studio version 17.5 Preview 2》