g+++s -g 选项相当于VS2010 cl编译器？
使用 g++ 和 -g 选项，我可以使用 gdb 进行调试。
Visual Studio 2010 cl.exe 编译器中的此选项等效于什么？
此页面具有不同的库（调试/发布）进行链接。
如果我使用 cl.exe 使用调试选项进行编译，是否必须使用相应的库链接选项（/MD/MT 与 /MDd/MTd）？
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)?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这个问题有几个单独的部分：如何告诉编译器/链接器生成并保留“调试信息”（源代码和目标代码之间的映射），如何告诉编译器以不同的方式编译代码以使调试更容易（想想assert() 和#ifdef _DEBUG)，以及链接到项目中的预编译库是否包含调试信息。
-Zi（给 CL 编译器的标志，告诉它生成调试信息）相当于 gcc 的 -g 标志。
（还有其他形式的 -Z 选项： -ZI 如果您希望在 Visual Studio IDE 中支持“编辑并继续”，但如果您使用 IDE，您可能会使用其编译器设置界面而不是直接操作它们，如果你想要旧的 CodeView 格式的调试信息，则使用 -Z7；每当我直接调用 CL 时，我总是想要 -Zi。）
请注意，使用 -Zi（或 -ZI）选项将生成一个通常，每个目录都有一个 .pdb 文件，但是当您将代码链接在一起时，它可能来自不同 .pdb 文件中表示的 .obj 文件，并且您还希望将这些单独的 .pdb 文件组合成一个表示您链接的代码的主文件一起——这就是链接器的 -debug 开关的用途。
另请注意：这可能听起来违反直觉，但始终使用 -Zi （对于 CL）和 -debug （对于 link.exe）。即使对于您要发布的代码也是如此。它不会增加可执行文件的大小，也不会向客户泄露机密，因为调试信息位于单独的 .pdb 文件中（您不会将其发送给客户）。如果您有机会需要对其进行调试，您将需要 .pdb。 （-Zi 甚至与优化不兼容，尽管 -ZI 是不兼容的。因此，您可能希望使用 -ZI 编译“调试”版本，并使用“-Zi -O2”编译“发布”版本。）
至于库：您并不严格需要将 C 运行时库的 debug/release 属性与您的代码是否包含调试信息相匹配，但这通常是一个好主意 - 如果您要调试您希望能够的项目调试所有这些，如果您不打算调试它，则不需要额外的重量。使用给定库的调试/发布版本不会影响它是否具有可用的调试符号（希望编译该库的人理解我在上一段中提出的观点），但它会影响断言和额外的 #ifdef _DEBUG 等内容该库中的代码。
这适用于您链接的所有库，但尤其是 C 运行时库——微软向 malloc() 和 free() 添加了额外的错误检测代码。因此，如果您的项目中的任何内容都使用 CRT 库的调试风格，那么所有内容都应该如此。
在我看来，/M 选项（/MTd 和 /MDd）既奇怪又神奇——它们只是幕后发生的一组复杂的其他事情的别名。以 /MDd 为例，记录为“定义 _DEBUG、_MT 和 _DLL，并使应用程序使用运行时库的调试多线程和 DLL 特定版本。它还会导致编译器放置库名称 MSVCRTD。 lib 到 .obj 文件中。”在这里，它同时影响预处理器（定义 _DEBUG 和其他一些预处理器符号）和链接器（它实际上在源代码中放置了 #pragma comment(linker)）。如果您关心正在发生的事情并且不理解它，这可能会导致真正的问题 - 我见过很多不使用 IDE 的项目陷入有关 msvcrt.lib 和 msvcrtd.lib 的警告中当您了解如何安全地使用这些（/M 选项）时，您实际上不再需要它们了！我更喜欢让事情变得明确：直接在需要的地方指定“-D _DEBUG”，指定要显式链接的库（并使用 -nodefaultlib），然后不需要 /M 选项。
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.
您正在寻找调试信息生成之一选项（
/Z7、/Zi或/ZI）。如果您使用其中之一，还应该传递 /DEBUG 链接器选项。
您还需要链接到调试版本< /a> 运行时库（
/MDd或/MTd）。这很重要，因为这些版本与其发行版本不同（例如，它们的内存分配例程不兼容）。You're looking for one of the debug information generation options (
/Z7,/Zior/ZI).If you use one of those, you should also pass the /DEBUG option to the linker.
You will also need to link against the debug version of the runtime libraries (
/MDdor/MTd). This is important because these versions are different from their release counterparts (e.g. their memory allocations routines are not compatible).