visual-studio 将 /Zi 与 /Z7 用于 Visual Studio C++ 项目有什么影响?
声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow
原文地址: http://stackoverflow.com/questions/284778/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
What are the implications of using /Zi vs /Z7 for Visual Studio C++ projects?
提问by Zach Burlingame
Background
背景
There are several different debug flagsyou can use with the Visual Studio C++ compiler. They are:
有几种不同的调试标志可用于 Visual Studio C++ 编译器。他们是:
- (none)
- Create no debugging information
- Faster compilation times
- /Z7
- Produce full-symbolic debugging information in the .obj files using CodeView format
- /Zi
- Produce full-symbolic debugging information in a .pdb file for the target using Program Database format.
- Enables support for minimal rebuilds (/Gm) which can reduce the time needed for recompilation.
- /ZI
- Produce debugging information like /Zi except with support for Edit-and-Continue
- (没有任何)
- 不创建调试信息
- 更快的编译时间
- /Z7
- 使用 CodeView 格式在 .obj 文件中生成全符号调试信息
- /子
- 使用程序数据库格式在 .pdb 文件中为目标生成全符号调试信息。
- 启用对最小重建 (/Gm) 的支持,这可以减少重新编译所需的时间。
- /ZI
- 产生像 /Zi 这样的调试信息,除了支持 Edit-and-Continue
Issues
问题
The /Gm flag is incompatible with the /MP flag for Multiple Process builds(Visual Studio 2005/2008)
If you want to enable minimal rebuilds, then the /Zi flag is necessary over the /Z7 flag.
If you are going to use the /MP flag, there is seemingly no difference between /Z7 and /Zi looking at MSDN. However, the SCons documentationstates that you must use /Z7 to support parallel builds.
如果要启用最少的重建,则需要在 /Z7 标志上加上 /Zi 标志。
如果您打算使用 /MP 标志,在 MSDN 上看 /Z7 和 /Zi 之间似乎没有区别。但是,SCons 文档指出您必须使用 /Z7 来支持并行构建。
Questions
问题
What are the implications of using /Zi vs /Z7 in a Visual Studio C++ project?
Are there other pros or cons for either of these options that I have missed?
Specifically, what is the benefit of a single Program Database format (PDB) file for the target vs multiple CodeView format (.obj) files for each source?
在 Visual Studio C++ 项目中使用 /Zi 与 /Z7 的含义是什么?
我错过的这些选项中的任何一个还有其他优点或缺点吗?
具体来说,目标的单个程序数据库格式 (PDB) 文件与每个源的多个 CodeView 格式 (.obj) 文件的好处是什么?
References
参考
MDSN /Z7, /Zi, /ZI (Debug Information Format)
MSDN /MP (Build with Multiple Processes)
采纳答案by Ben Combee
Codeview is a much older debugging format that was introduced with Microsoft's old standalone debugger back in the "Microsoft C Compiler" days of the mid-1980s. It takes up more space on disk and it takes longer for the debugger to parse, and it's a major pain to process during linking. We generated it from our compiler back when I was working on the CodeWarrior for Windows in 1998-2000.
Codeview 是一种更古老的调试格式,它是在 1980 年代中期的“Microsoft C 编译器”时代随 Microsoft 旧的独立调试器引入的。它在磁盘上占用更多空间,调试器解析需要更长的时间,并且在链接期间处理是一个主要的痛苦。当我在 1998-2000 年为 Windows 开发 CodeWarrior 时,我们从我们的编译器中生成了它。
The one advantage is that Codeview is a documented format, and other tools can often process it when they couldn't deal with PDB-format debug databases. Also, if you're building multiple files at a time, there's no contention to write into the debug database for the project. However, for most uses these days, using the PDB format is a big win, both in build time and especially in debugger startup time.
一个优点是 Codeview 是一种文档格式,当其他工具无法处理 PDB 格式的调试数据库时,通常可以对其进行处理。此外,如果您一次构建多个文件,则不会争用写入项目的调试数据库。然而,对于如今的大多数用途,使用 PDB 格式是一个巨大的胜利,无论是在构建时间还是在调试器启动时间。
回答by scobi
One advantage of the old C7 format is that it's all-in-one, stored in the EXE, instead of a separate PDB and EXE. This means you can never have a mismatch. The VS dev tools will make sure that a PDB matches its EXE before it will use it, but it's definitely simpler to have a single EXE with everything you need.
旧 C7 格式的一个优点是它是一体式的,存储在 EXE 中,而不是单独的 PDB 和 EXE。这意味着您永远不会出现不匹配的情况。VS 开发工具将确保 PDB 在使用它之前与其 EXE 匹配,但是拥有一个包含您需要的一切的单个 EXE 绝对更简单。
This adds new problems of needing to be able to strip debug info when you release, and the giant EXE file, not to mention the ancient format and lack of support for other modern features like minrebuild, but it can still be helpful when you're trying to keep things as simple as possible. One file is easier than two.
这增加了需要能够在发布时去除调试信息和巨大的 EXE 文件的新问题,更不用说古老的格式和缺乏对其他现代功能(如 minrebuild)的支持,但是当您使用它时它仍然会有所帮助试图让事情尽可能简单。一个文件比两个文件容易。
Not that I ever use C7 format, I'm just putting this out there as a possible advantage, since you're asking.
并不是说我曾经使用过 C7 格式,我只是把它作为一个可能的优势放在那里,因为你在问。
Incidentally, this is how GCC does things on a couple platforms I'm using. DWARF2 format buried in the output ELF's. Unix people think they're so hilarious. :)
顺便说一下,这就是 GCC 在我使用的几个平台上做事的方式。DWARF2 格式隐藏在输出 ELF 中。Unix 人认为他们太搞笑了。:)
BTW the PDB format can be parsed using the DIA SDK.
顺便说一句,可以使用DIA SDK解析 PDB 格式。
回答by ElektroKraut
There is one more disadvantage for /Z7: It's not compatible with incremental linking, which may alone be a reason to avoid it. Link: http://msdn.microsoft.com/en-us/library/4khtbfyf%28v=vs.100%29.aspx
/Z7 还有一个缺点:它与增量链接不兼容,这可能是避免它的一个原因。链接:http: //msdn.microsoft.com/en-us/library/4khtbfyf%28v=vs.100%29.aspx
By the way: even though Microsoft says a full link (instead of an incremental) is performed when "An object that was compiled with the /Yu /Z7 option is changed.", it seems this is only true for static libraries build with /Z7, not for object files.
顺便说一句:即使微软说当“使用 /Yu /Z7 选项编译的对象发生更改时执行完整链接(而不是增量链接)。”,似乎这仅适用于使用 / 构建的静态库Z7,不适用于目标文件。
回答by Trass3r
/Z7keeps the debug info in the .obj files in CodeView format and lets the linker extract them into a .pdb while /Ziconsolidates it into a common .pdb file during compilation already by sync'ing with mspdbsrv.exe.
/Z7将调试信息保存在 CodeView 格式的 .obj 文件中,并让链接器将它们提取到 .pdb 中,同时/Zi在编译期间通过与 mspdbsrv.exe 同步将其合并到一个通用的 .pdb 文件中。
So /Z7means more file IO, disc space being used and more work for the linker as there is lots of duplicate debug info in these obj files. But it also means every compilation is independent and thus can actually still be faster than /Ziwith enough parallelization.
这/Z7意味着更多的文件 IO、使用的磁盘空间和链接器的更多工作,因为这些 obj 文件中有很多重复的调试信息。但这也意味着每个编译都是独立的,因此实际上仍然比/Zi足够的并行化要快。
By now they've improved the /Zisituation though by reducing the inter-process communication with mspdbsrv.exe: https://docs.microsoft.com/en-us/cpp/build/reference/zf
到目前为止,他们已经/Zi通过减少与 mspdbsrv.exe 的进程间通信来改善这种情况:https://docs.microsoft.com/en-us/cpp/build/reference/zf
Another use-case of /Z7is for "standalone" (though larger) static libraries that don't require shipping a separate .pdbif you want that. That also prevents the annoying issues arising from the awful default vcxxx.pdbname cl uses as long as you don't fix it with a proper https://docs.microsoft.com/en-us/cpp/build/reference/fd-program-database-file-name, which most people forget.
的另一个用例/Z7是“独立”(尽管更大)静态库,.pdb如果需要,不需要单独传送。这也可以防止可怕的过失而引起的恼人问题vcxxx.pdb名称CL用途,只要你不正确的修复https://docs.microsoft.com/en-us/cpp/build/reference/fd-program- database-file-name,大多数人忘记了。
/ZIis like /Zibut adds additional data etc. to make the Edit and Continue feature work.
/ZI就像/Zi但添加了额外的数据等,使编辑并继续功能工作。
回答by Trass3r
Another disadvantage of /Z7 is the big size of the object files. This has already been mentioned here, however this may escalate up to the point where the linker is unable to link the executable because it breaks the size limit of the linker or the PE format (it gives you linker error LNK1248). It seems Visual Studio or the PE format has a hard limit of 2GB (also on x64 machines). When building a debug version you may run into this limit. It appears this does not only affect the size of the final compiled executable, but also temporary data. Only Microsoft knows about the linker internals, but we ran into this problem here (though the executable was of course not 2gigs large, even in debug). The problem miraculously went away and never came back when we switched the project to /ZI.
/Z7 的另一个缺点是目标文件很大。这已经在这里提到了,但是这可能会升级到链接器无法链接可执行文件的程度,因为它打破了链接器或 PE 格式的大小限制(它会给你链接器错误 LNK1248)。似乎 Visual Studio 或 PE 格式有 2GB 的硬限制(也在 x64 机器上)。在构建调试版本时,您可能会遇到此限制。看来这不仅会影响最终编译的可执行文件的大小,还会影响临时数据。只有微软知道链接器的内部结构,但我们在这里遇到了这个问题(尽管可执行文件当然不是 2gigs 大,即使在调试中)。当我们将项目切换到 /ZI 时,问题奇迹般地消失了,再也没有出现过。

