g++ 的 -g 选项相当于 VS2010 cl 编译器? [英] The g++'s -g option equivalent to VS2010 cl compiler?

问题描述

使用带有 -g 选项的 g++，我可以使用 gdb 进行调试.

With g++ with -g option, I can use gdb for debugging purposes.

Visual Studio 2010 cl.exe 编译器与此选项的等效项是什么?

What's the equivalent to this option with Visual Studio 2010 cl.exe compiler?

这个页面有不同的库(调试/发布)用于链接.

This page has different libraries (debug/release) for linking.

如果我使用 cl.exe 的调试选项进行编译，是否必须使用相应的库链接选项(/MD/MT vs/MDd/MTd)?

If I compile with debugging option with cl.exe, do I have to use the corresponding library linking options (/MD/MT vs /MDd/MTd)?

推荐答案

这个问题有几个单独的部分:如何告诉编译器/链接器生成和保留调试信息"(源代码和目标代码之间的映射))，如何告诉编译器以不同的方式编译代码以使调试更容易(想想 assert() 和 #ifdef _DEBUG)，以及您链接到项目中的预编译库是否包含调试信息.

There are a few separate pieces to this question: how to tell the compiler/linker to generate and preserve "debug information" (mapping between source code and object code), how to tell the compiler to compile the code differently to make debugging easier (think of assert() and #ifdef _DEBUG), and whether the precompiled libraries you link into your project include debugging information.

-Zi(CL 编译器的标志，告诉它生成调试信息)相当于 gcc 的 -g 标志.

-Zi (flag to the CL compiler to tell it to generate debug information) is the equivalent of gcc's -g flag.

(还有其他形式的 -Z 选项:-ZI 如果您希望 Visual Studio IDE 中的编辑并继续"支持，但如果您使用的是 IDE，您可能正在使用它的编译器接口设置而不是直接操作它们，如果您想要旧的 CodeView 格式的调试信息，则使用 -Z7；每当我直接调用 CL 时，它总是我想要的 -Zi.)

(There are other forms of the -Z option: -ZI if you want the "edit and continue" support in the Visual Studio IDE, but if you're using the IDE you're probably using its interface to the compiler settings instead of manipulating them directly, and -Z7 if you want the old CodeView-format debug information; whenever I've invoked CL directly it's always been -Zi that I wanted.)

请注意，使用 -Zi(或 -ZI)选项通常会为每个目录生成一个 .pdb 文件，但是当您将代码链接在一起时，它可能来自不同 .pdb 文件中表示的 .obj 文件，并且您还想将这些单独的 .pdb 文件组合成一个代表您链接在一起的代码的主文件 - 这就是链接器的 -debug 开关的用途.

Note that using the -Zi (or -ZI) option will generate a .pdb file per directory, usually, but when you link code together, it may have come from .obj files represented in different .pdb files, and you also want to combine those separate .pdb files into a master one representing the code you linked together -- this is what the -debug switch for the linker is for.

另请注意:这听起来可能违反直觉，但始终使用 -Zi(用于 CL)和 -debug(用于 link.exe).即使对于您要发布的代码.它不会增加可执行文件的大小，也不会向客户泄露机密，因为调试信息位于单独的 .pdb 文件中(您不会将其发送给客户).如果您有任何机会必须调试它，那么您将需要 .pdb.(-Zi 甚至与优化不兼容，尽管 -ZI 是.因此，您可能希望使用 -ZI 编译调试"版本，而使用-Zi -O2"编译发布"版本.)

Also note: this may sound counterintuitive, but always use -Zi (for CL) and -debug (for link.exe). Even for code you're going to release. It doesn't increase the size of your executable, or give away secrets to your customers, since the debug information goes in a separate .pdb file (which you won't ship to customers). If there's any chance you're ever going to have to debug it, you're going to want the .pdb. (-Zi isn't even incompatible with optimizations, though -ZI is. So you might want to compile your "debug" builds with -ZI, and your "release" builds with "-Zi -O2".)

至于库:您不需要严格地将 C 运行时库的调试/发布属性与您的代码是否包含调试信息相匹配，但这通常是一个好主意——如果您要调试您希望能够调试所有项目，如果您不打算调试它，则不需要额外的重量.使用给定库的调试/发布版本不会影响它是否有可用的调试符号(希望编译库的人理解我在上一段中提出的观点)，但它会影响诸如 assert 和 extra #ifdef _DEBUG 之类的东西该库中的代码.

As for the libraries: you don't strictly need to match the debug/release property of the C runtime library with whether your code includes debugging information, but it's usually a good idea -- if you're going to debug the project you want to be able to debug all of it, and if you're not going to debug it you don't need the extra weight. Using debug/release versions of a given library won't affect whether it has debug symbols available (hopefully, if whoever compiled the library understood the point I made in the previous paragraph), but it will affect things like assert and extra #ifdef _DEBUG code in that library.

这适用于您链接的所有库，尤其是 C 运行时库——微软向 malloc() 和 free() 添加了额外的错误检测代码.因此，如果您的项目中有任何内容使用了 CRT 库的调试风格，那么所有内容都应该如此.

This goes for all libraries you link with, but especially for the C runtime library -- Microsoft added extra error-detection code to malloc() and free(). So if anything in your project is using the debug flavor of the CRT library, all of it should be.

在我看来，/M 选项(/MTd 和/MDd)既奇怪又神奇——它们只是幕后发生的一组复杂其他内容的别名.以/MDd 为例，记录在定义 _DEBUG、_MT 和 _DLL 并导致您的应用程序使用调试多线程和 DLL 特定版本的运行时库.它还导致编译器放置库名称 MSVCRTD.lib 到 .obj 文件中."在这里，它同时影响预处理器(定义 _DEBUG 和一些其他预处理器符号)和链接器(它实际上在源代码中放置了 #pragma 注释(链接器)).如果您关心正在发生的事情并且不理解它，这可能会导致真正的问题——我已经看到很多不使用 IDE 的项目陷入关于 msvcrt.lib 和 msvcrtd.lib 的警告中被链接等.当您了解如何安全地使用这些(/M 选项)时，您就不再真正需要它们了！我更喜欢让事情变得明确:在我需要的地方直接指定-D _DEBUG"，指定要显式链接的库(并使用 -nodefaultlib)，然后不需要/M 选项.

The /M options (/MTd and /MDd) are weird and magic, in my opinion -- they're just aliases for a complicated set of other stuff going on behind the scenes. Take /MDd for example, documented to "Defines _DEBUG, _MT, and _DLL and causes your application to use the debug multithread- and DLL-specific version of the run-time library. It also causes the compiler to place the library name MSVCRTD.lib into the .obj file." Here, it's affecting both the preprocessor (defining _DEBUG and some other preprocessor symbols) and the linker (it actually puts a #pragma comment(linker) in your source code). If you care about what's going on and don't understand it, this can cause real problems -- I've seen a lot of projects that don't use the IDE get bogged down in warnings about both msvcrt.lib and msvcrtd.lib being linked in, etc. By the time you understand how to use these (/M options) safely, you don't really need them any more! I prefer to make things explicit: specify "-D _DEBUG" directly where I need it, specify which libraries to link with explicitly (and use -nodefaultlib), and then the /M options aren't needed.

这篇关于g++ 的 -g 选项相当于 VS2010 cl 编译器?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！