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

问题描述

使用g ++与 -g选项，我可以使用gdb进行调试。

与Visual Studio 2010 cl.exe编译器相当的这个选项是什么？

此页面具有不同的库（调试/释放）用于链接。

如果我使用cl.exe编译调试选项，是否必须使用相应的库链接选项（/ MD / MT vs / MDd / MTd）？ p>

解决方案

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

-Zi（标志到CL编译器来告诉它生成调试信息）相当于gcc的-g标志。

（还有其他形式的-Z选项：-ZI如果你想在Visual Studio IDE中支持编辑和继续，但是如果你使用的是IDE，那么你可能正在使用它的编译器接口设置，而不是直接操作它们，而-Z7如果你哇没有旧的CodeView格式调试信息;每当我直接调用CL，它一直是我想要的-Zi。）

请注意，使用-Zi（或-ZI）选项将生成一个.pdb文件通常，但是当您将代码链接在一起时，它可能来自不同.pdb文件中的.obj文件，并且还要将这些单独的.pdb文件合并到一个代表链接在一起的代码的主文件中。这是链接器的-debug开关是为。

另请注意：这可能听起来违反直觉，但总是使用-Zi（对于CL）和-debug link.exe）。即使你要发布的代码。它不会增加您的可执行文件的大小，或放弃您的客户的秘密，因为调试信息进入单独的.pdb文件（您不会发送给客户）。如果你有机会去调试它，那么你将要使用.pdb。 （-Zi甚至与优化不兼容，尽管-ZI是，所以你可能想用-ZI编译你的调试版本，你的release版本使用-Zi -O2编译。）

对于库：您不需要严格地将C运行时库的debug / release属性与您的代码是否包含调试信息进行匹配，但通常是一个好主意 - 如果要调试项目，您可以调试所有这些项目，如果您不想调试它，则不需要额外的重量。使用给定库的调试/发布版本不会影响是否有可用的调试符号（希望如果谁编译库了解我在上一段中提到的点），但它会影响如assert和extra #ifdef _DEBUG该库中的代码。

这是您连接的所有库，特别是对于C运行时库 - Microsoft向malloc（）添加了额外的错误检测代码，自由（）。所以如果您的项目中的任何内容都使用了CRT库的调试风格，那么它应该是所有的。

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

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

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

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

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

解决方案

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 (flag to the CL compiler to tell it to generate debug information) is the equivalent of gcc's -g flag.

(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.)

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.

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".)

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.

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.

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屋！