如何在 MacPorts gcc 4.5 中调试 C++0x 程序？

Posted 2023-02-22

【中文标题】如何在 MacPorts gcc 4.5 中调试 C++0x 程序？

【英文标题】：How do I debug C++0x programs in MacPorts gcc 4.5?

【发布时间】：2010-07-28 14:12:02

【问题描述】：

我正在尝试调试一个简单的 c++ 程序，但 gdb 找不到库的目标文件（或没有可用的调试信息），而且它似乎也找不到我的可执行文件的调试符号。

我在 OSX 10.5.8 上，使用 macports，我用

编译我的代码

g++-mp-4.5 -Wall -pedantic -std=c++0x -g -ggdb -I/opt/local/include -L/opt/local/lib -lgsl -static-libstdc++ MCMC-simplex.cpp -o mcmc

（只有一个文件，g++-mp-4.5是gcc/g++ 4.5的macports可执行文件）

当我尝试在生成的可执行文件上运行 gdb 时，我收到许多表单的错误消息（在启动时）

警告：找不到目标文件“/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_gcc45/work/build/i386-apple-darwin9/libgcc/trunctfdf2_s.o” - 没有可用的调试信息“../../../gcc-4.5.0/libgcc/../gcc/config/soft-fp/trunctfdf2.c”。

这对我来说表明 macports 在构建过程中存在错误（似乎 gdb 正在临时构建目录中寻找目标文件）。

我应该补充一点，当我尝试在 gdb（Apple 提供的那个）中查看我的程序时，它会尝试在 /var/tmp 中查找随机的 .s 文件，这对我来说听起来像是一个汇编文件。这就是为什么我说它似乎也找不到我的程序的调试符号。

当我尝试 MacPorts gdb 7.1 时，我得到了

警告：`/var/folders/Xa/XaqHO9PeEC8K-Nrd0L9xWk+++TM/-Tmp-//cc2IvFto.o'：无法打开以读取符号：没有这样的文件或目录。 （未找到调试符号）...完成。

Apple 的 gdb 给出的许多错误消息都没有（尽管最终结果是相同的）。

有没有人遇到过这个问题，并想出了解决方案？

【参考方案1】：

与其他 UNIXen 不同，在 MacOS 上，调试信息不​​会链接到可执行文件中。相反，可执行文件有一个链接到其中的目标文件列表，调试器会在这些单独的目标文件中查找调试信息。

如果删除目标文件，则无法调试。

当您在“单步”中编译和链接可执行文件时，GCC 会这样做：

创建程序集文件/tmp/[random-string].s 组装成/tmp/[random-string].o 将/tmp/[random-string].o 与crt0.o、libc 等链接到mcmc 可执行文件中。 删除/tmp/[random-string].o 和.s

这是阻止您调试的最后一步。

解决方案：

g++-mp-4.5 -Wall -pedantic -std=c++0x -g -ggdb -c MCMC-simplex.cpp
g++-mp-4.5 MCMC-simplex.o -lgsl -static-libstdc++ -o mcmc

这会将MCMC-simplex.o留在当前目录中，并允许GDB在其中找到调试信息。

【讨论】：

谢谢！这使我能够调试我的代码，但我仍然收到类型警告的错误：`/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_gcc45/work/build/i386-apple-darwin9/libgcc/_powixf2_s。 o'：无法打开读取符号：没有这样的文件或目录。我想我应该归咎于 MacPorts。

这与俄罗斯人所说的问题相同，只是 gcc 库的 .o 文件不存在。你想进入 gcc 库吗？您可以告诉 macports 将编译器对象留在周围。请参阅 macports.conf 选项 portautoclean

@Mark，哪个选项将.o 文件与 macports.conf 一起保存？

【参考方案2】：

嗯，继续执行单个编译和链接步骤的另一个“技巧”是添加-save-temps=obj 到你的 g++ 命令行，这样

4 删除 /tmp/[random-string].o 和 .s

实际上有点不执行（实际上，您最终在您正在构建的目录中拥有规范的 SOURCE.o 和 SOURCE.s 文件，而不是在某些临时文件夹中的 RANDOM-STRING.[os] ，但来自定位调试符号的观点很好

【讨论】：

太糟糕了，我不能将多个问题称为“最好的”。不过，感谢您的信息！

谢谢！这在尝试使用 gdb 调试 fortran 程序时很有帮助。对于 gfortran 4.4，它似乎无法识别标志的 [=dir] 部分，因此您必须只使用 -save-temps。

【参考方案3】：

在我看来，您有两个问题：1) 没有可执行文件的调试符号和 2) 一些生成警告的共享库没有调试符号。我也有问题2）。受雇的俄罗斯人回答了 1) 并为我指出了正确的方向 2)。

首先，如果您不需要调试警告中提到的库，则可以安全地忽略它们。但当然，这些警告很烦人，并且可能隐藏其他问题。在您和我的情况下，MacPorts 安装的库应该已经剥离了调试符号，但没有。正如 Employed Russian 所说，导致警告的原因是，符号本身保存在构建过程中生成的目标文件中，而不是安装的库中。库将指向目标文件的指针存储为它们（最小）调试信息的一部分。

您可以使用 strings 命令验证这一点。如果您在加载 libsomething.dylib 时收到 /crazy/path/to/something.o 的警告：

strings - libsomething.dylib | grep something.o

请注意，您需要“-”（这是我第一次遇到的问题）。

要修复它，像这样剥离调试信息：

strip -S libsomething.dylib

之后，“dwarfdump --file-stats libsomething.dylib”应显示“STABS 调试”部分为空。 （目标文件的链接以 STABS 调试格式存储。）

没有更多丑陋的警告......耶！

这方式太难了。

【讨论】：

我遇到了这个问题，strip -S 对我们构建的一些 dylib 进行了处理，但我还必须在 /Library/Frameworks/Blah.framework/Versions/Current/Blah 中剥离一些已安装的框架。