如何在 MacPorts gcc 4.5 中调试 C++0x 程序？
我有一个简单的 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 没有给出任何错误消息（尽管最终结果是相同的）。
有没有人遇到过这个问题，并提出了解决方案？
I have a simple c++ program I am trying to debug, but gdb cannot find the object file for the libraries (or no debug info is available), and it does not seem able to find the debug symbols for my executable either.
I am on OSX 10.5.8, with macports, and I compile my code with
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
(there is only one file, and g++-mp-4.5 is the macports executable for gcc/g++ 4.5 )
When I try running gdb on the resulting executable, I get many error messages (at startup) of the form
warning: Could not find object file "/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" - no debug information available for "../../../gcc-4.5.0/libgcc/../gcc/config/soft-fp/trunctfdf2.c".
which to me indicates that macports has a bug during its build (it seems like gdb is looking for the object files in the temporary build directory).
I should add that when I try to see my programs listing in gdb (the one provided by Apple), it tries to look for a random .s file in /var/tmp, which to me sounds like an assembler file. That is why I say it does not seem able to find the debug symbols for my program either.
When I try MacPorts gdb 7.1, I get
warning: `/var/folders/Xa/XaqHO9PeEC8K-Nrd0L9xWk+++TM/-Tmp-//cc2IvFto.o': can't open to read symbols: No such file or directory.
(no debugging symbols found)...done.
and none of the many error messages that Apple's gdb gives out (although the end result is the same).
Has anyone come across this problem, and came up with a solution?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
与其他 UNIXen 不同，在 MacOS 上，调试信息未链接到可执行文件中。相反，可执行文件具有链接到其中的目标文件列表，调试器在这些单独的目标文件中查找调试信息。
如果删除目标文件，则无法进行调试。
当您以“单步”方式编译和链接可执行文件时，GCC 会执行以下操作：
/tmp/[random-string].s/tmp/[random-string] ].o/tmp/[random-string].o与crt0.o、libc等链接到 <代码>mcmc可执行文件。/tmp/[random-string].o和.s这是最后一步，它会阻止您进行调试。
解决方案：
这会将 MCMC-simplex.o 保留在当前目录中，并允许 GDB 在其中查找调试信息。
Unlike other UNIXen, on MacOS the debug info is not linked into the executable. Instead, the executable has a list of object files which were linked into it, and the debugger looks for debug info in these individual object files.
If you remove the object files, then you can't debug.
When you compile and link the executable in "single step", GCC does this:
/tmp/[random-string].s/tmp/[random-string].o/tmp/[random-string].owithcrt0.o,libc, etc. intomcmcexecutable./tmp/[random-string].oand.sIt is that last step which prevents you from debugging.
Solution:
This will leave
MCMC-simplex.oin the current directory, and will allow GDB to find debug info in it.那么，继续执行单个编译和链接步骤的另一个“技巧”是添加
-save-temps=obj到你的 g++ 命令行，以便
实际上没有执行（实际上，您最终在构建的目录中拥有规范的 SOURCE.o 和 SOURCE.s 文件，而不是 RANDOM-STRING .[os] 在一些临时文件夹中，但从定位调试符号的角度来看这很好
Well, another "trick" to keep going with a single compile-and-link step would be to add
-save-temps=objto your g++ command line so that
is actually sort of not performed (actually you end up having the canonical SOURCE.o and SOURCE.s files in the directory where you're building instead of RANDOM-STRING.[os] in some temp folders, but from the point of view of locating debugging symbols that's fine
在我看来，您有两个问题：1）可执行文件没有调试符号，2）某些生成警告的共享库没有调试符号。我也遇到了问题2）。受雇的俄罗斯人回答了 1) 并为我指明了 2) 的正确方向。
首先，如果您不需要调试警告中提到的库，那么可以安全地忽略它们。但当然，这些警告很烦人，并且可能隐藏其他问题。在您和我的情况下，MacPorts 安装的库应该已删除调试符号，但事实并非如此。正如《Employed Russian》所说，引起警告的原因是符号本身保存在构建过程中生成的目标文件中，而不是保存在已安装的库中。这些库存储指向目标文件的指针作为其（最小）调试信息的一部分。
您可以使用 strings 命令验证这一点。如果您在加载 libsomething.dylib 时收到无法找到 /crazy/path/to/something.o 的警告：
请注意，您需要“-”（这是我第一次遇到的情况）。
要修复它，请像这样删除调试信息：
然后，“dwarfdump --file-stats libsomething.dylib”应该显示“STABS debug”部分为空。 （目标文件的链接以 STABS 调试格式存储。）
不再有丑陋的警告......耶！
那太难了。
It seems to me you had two problems: 1) no debug symbols for executable and 2) no debug symbols for some shared libraries that generated warnings. I was also having problem 2). Employed Russian answered 1) and pointed me in the right direction for 2).
First, if you don't need to debug the libraries mentioned in the warnings, then they can be safely ignored. But of course the warnings are annoying and could hide other problems. In your case and mine, the libraries installed by MacPorts should have had debug symbols stripped, but didn't. The reason that causes a warning is, as Employed Russian says, because the symbols themselves are kept in object files generated during the build process and not in the installed libraries. The libraries store pointers to the object files as part of their (minimal) debug information.
You can verify this with the strings command. If you're gettings warnings that /crazy/path/to/something.o can't be found when loading libsomething.dylib:
Note that you need the '-' (this got me the first time).
To fix it, strip debugging info like so:
Afterwards, 'dwarfdump --file-stats libsomething.dylib' should show that the "STABS debug" section is empty. (The links to object files are stored in STABS debug format.)
No more ugly warnings.. yay!
That was way too hard.