3

gdb 新手，所以我希望我没有忽略一些明显的东西……（如果我这样做了，也许一个好心的人会指出它吗？；）

我正在 OS X Lion 下调试 GCC C++ 应用程序。由于它在 STL 上相当繁重，我真的很想使用支持 python 的 GDB 版本（即 >=v7）来漂亮地打印容器。我的应用程序被分成一个后端库 (.dylib) 来完成所有繁重的工作，以及一个非常简单的前端应用程序。所有源代码和二进制文件都在一个公共源路径下，并且所有内容都已使用调试符号编译（我尝试了 -g 和 -ggdb）。

在 XCode 中使用 GDB 版本（标识为“GNU gdb 6.3.50-20050815（Apple 版本 gdb-1820）”），在回溯中显示帧的源代码行按预期开箱即用，无论各自是否调用发生在前端应用程序或后端库中：

(gdb) f 12

#12 0x000000010002ddc5 in FL3D::Resource::createMesh_ (this=0x7fff5fbff7c8, fl3d=@0x7fff5fbff1f8, id=) at /Development/workspace/fl3d/libfl3d/resource.cpp:234

第234章

(gdb)

到目前为止，一切都很好。另一方面，GDB 7.5 和 7.4.1 拒绝向我提供库中的任何源代码行：

(gdb) f 12

#12 0x000000010002ddc5 in FL3D::Resource::createMesh_(FL3D::FL3DParser&, std::string) () 来自 /Development/workspace/fl3d/libfl3d/build/libfl3d.dylib

(gdb)

我对给出的不同响应感到非常困惑——gdb6 打印到源文件的正确路径和正确的行，而 gdb7 获得了正确的函数原型（据说是从 .dylib 的调试符号中读取的？），但没有似乎对来源一无所知。有趣的是，它确实显示了前端 main() 函数中调用的相应源代码行！

我已经尝试使用“dir libfl3d”手动设置库源文件的路径，但这并没有改变任何东西。我还注意到，当我运行应用程序时，gdb6 多次说“读取共享库的符号”，而 gdb7 没有——但这些符号似乎不是问题，因为它们似乎都被两个版本正确解决了？

我在这里束手无策。任何指针？

4

1 回答 1

2

Apple gdb 正在显示调试信息，因为它知道如何在此平台上查找和解析 DWARF。您显示的 gdb 版本 7 是一个 gdb，它不知道如何在 Mac OS X 系统上找到 DWARF 调试信息——您在上面显示的输出是 no-debug-info 的样子。我的猜测是 FSF gdb 版本 7 对 Mac OS X 的支持并没有引起很多关注，我会犹豫是否推荐在这个平台上使用它。

正如bames53 所指出的，此时您最好在 Mac OS X 上使用 LLDB。所有支持工作都在调试器中进行，Objective-C / C++ 容器支持正在迅速添加到 LLDB 而不是 gdb。Apple 提供的 gdb 正在报废，未来所有用户都将切换到 LLDB。

试试 lldb。它有点不同，但它非常好。有一个备忘单，很多人一开始觉得很有用，它显示了 gdb 和 lldb 命令等价。 http://lldb.llvm.org/lldb-gdb.html

于 2012-11-16T21:26:18.920 回答