对于我的项目，发布版本（使用-O2 标志编译）比调试版本（使用-g -O0 标志编译）具有更高的性能。
所以我必须使用发布版本。
但是，在生产环境中，发布程序有时会产生核心转储。
然后我使用gdb xxx core 调试核心转储文件，但没有足够的信息。
我不关心程序或任何其他文件的大小。我想要最好的性能和最详细的调试信息。
我该怎么办？
【问题讨论】：
-g 与优化选项一起使用——它不会影响代码的性能！
标签： c++ c++11 gdb g++ coredump
我想要最好的表现
我该怎么办？
启用优化。
我想要...最详细的调试信息。
我该怎么办？
禁用优化（或者如果您的编译器支持此类选项：仅启用不干扰调试的优化；-Og 在 g++ 的情况下）并启用调试符号。
您可能会注意到，这些要求存在冲突。
从发布中调试转储的一个不错的折衷方案是启用优化并启用构建的调试信息，特别是考虑到...
我不在乎程序或任何其他文件的大小。
这是调试信息主要影响的。除非您关心程序的大小，否则无需避免启用调试信息。
【讨论】：
您还想设置-fno-omit-frame-pointer，以便在调试时知道自己在哪里。它会减慢执行速度，因为可用的寄存器较少，但调试是性能和信息之间的折衷（有时您需要这些来发现编译器在发布模式下假设了事情！）。
CMake 默认使用-O3 发布，-O2 -g 发布带有调试信息（对调试和分析有用），因此您有一个良好的开始，只需添加帧指针以获得更好的上下文。
是的，在生产中进行调试？可怕的。寻找复制者。
【讨论】：
-fno-omit-frame-pointer。
x86_64 上，GDB 完全有能力告诉您内联函数，以便通过调试信息优化构建。
您应该使用-g -O2 进行编译，并且（如果您确定有必要）将调试符号剥离到一个单独的符号文件。我不记得确切的步骤，因为我通常让dh-strip 在构建包时为我做这件事，但想法是符号不会在程序进程中消耗内存 - 你将它们加载到调试器中。
【讨论】：
-gdoes not更改生成的代码。它只添加调试信息。因此它should not 影响性能。
您应该调查您看到性能差异的原因 - 这可能会揭示一些有用的信息。
优化设置是影响性能的设置。如果您需要使用它们，请尝试-Og optimisation setting。它将启用不干扰调试的优化。
最后，生产环境通常不是调试的好地方。您的其他环境应设计为重现生产中可能出现的所有错误。目标是确保您永远不会在生产中遇到新错误。当然在实践中非常困难，但是考虑花更少的时间在生产环境上进行调试，而花更多的时间让您的其他环境紧密匹配，以便您可以识别（可能通过比较日志）然后在那里重现错误。作为一项好处，您可以在它们进入生产环境之前发现更多错误。
【讨论】：
-O 设置。抱歉，我的回答基本上没有意义。