如何在Mac OS X上运行自制的GDB版本？

Question

我正在尝试使用gdb在Eclipse中调试C++程序.我认为它在我的main()函数中工作正常,但是在我尝试查看变量的值时,它会给我一个警告:

Failed to execute MI command:
-data-evaluate-expression variable
Error message from debugger back end:
Could not find the frame base for "Class::method()".`

在搜索互联网之后,我很难理解这个错误的含义或找出如何解决问题.Stack Overflow 还有一些类似的问题(这里和这里).

由于Apple的Xcode命令行工具已经过时了(请参阅gcc和gdb问题),我需要使用自己的自制版本.我不知道这些工具的设置中是否有我可能错过的东西.

我可以使用gdb从命令行调试,我遇到了同样的错误:"Could not find the frame base for "Class::method()"所以我很确定它不是Eclipse的问题.

是否有任何事情可能导致这个问题？

• Mac OS X 10.8.5(Mountain Lion)
• Eclipse 4.2.1(Juno)
• GCC 4.8.2(家酿)(与-O0和-g3)
• gdb 7.6.2(自制和编码)

更新:

我也看到了这条线:

BFD: /System/Library/Frameworks/CFNetwork.framework/Versions/A/CFNetwork(i386:x86-64): unknown load command 0x20

接下来是几个警告:

warning: Could not open OSO archive file "/private/tmp/gcc48-KqoQ/gcc-4.8.2/build/x86_64-apple-darwin12.5.0/libstdc++-v3/src/../libsupc++/.libs/libsupc++convenience.a"
warning: Could not open OSO archive file "/private/tmp/gcc48-KqoQ/gcc-4.8.2/build/x86_64-apple-darwin12.5.0/libstdc++-v3/src/../src/c++11/.libs/libc++11convenience.a"
warning: Could not open OSO archive file "/private/tmp/gcc48-KqoQ/gcc-4.8.2/build/x86_64-apple-darwin12.5.0/libstdc++-v3/src/../src/c++98/.libs/libc++98convenience.a"
warning: `/private/tmp/gcc48-KqoQ/gcc-4.8.2/build/x86_64-apple-darwin12.5.0/libstdc++-v3/src/.libs/compatibility-atomic-c++0x.o': can't open to read symbols: No such file or directory.
warning: `/private/tmp/gcc48-KqoQ/gcc-4.8.2/build/x86_64-apple-darwin12.5.0/libstdc++-v3/src/.libs/compatibility-c++0x.o': can't open to read symbols: No such file or directory.
warning: `/private/tmp/gcc48-KqoQ/gcc-4.8.2/build/x86_64-apple-darwin12.5.0/libstdc++-v3/src/.libs/compatibility-chrono.o': can't open to read symbols: No such file or directory.
warning: `/private/tmp/gcc48-KqoQ/gcc-4.8.2/build/x86_64-apple-darwin12.5.0/libstdc++-v3/src/.libs/compatibility-debug_list-2.o': can't open to read symbols: No such file or directory.
...

继续几行.谷歌搜索"gdb bfd unknown load command"显示很多站点没有任何解决方案,但它们似乎都表明非苹果版本的gdb和Mac OS X 10.8+之间可能存在冲突.

任何见解都会有所帮助!

Answer 1

就是因为名字乱了。名称与 GCC 和 Clang 的名称相同（它们通常共享相似的机制）。名称修改使得 C/C++ 方法和汇编过程可以具有相同的名称。看看 C 定义会发生什么：

void myfunc() {}

我们用来nm查看符号的二进制名称。用于nm --demangle查看未损坏的名称。编译文件的 Nm 输出为： ... 0000000000000000 T _myfunc ... 其他符号的数量取决于调试级别，请参阅 GCC 手册页了解 -O 和 -g 选项。正如我们所看到的，有一个数字。它是十六进制的。在32位机器上有8位，在64位机器上有16位（因为n位CPU意味着n位代表一个指针，该符号实际上是二进制文件中的指针）。然后我们有符号类型。现在只有两个值有趣：T是 C/C++/... 方法，t是汇编程序。看看如果我们编译以下汇编代码会发生什么：

myproc:

GCC 和 Clang 在编译 Assembly 时不应推送调试符号，因此nm输出可能如下所示：

0000000000000000 t myproc

汇编过程名称不会被破坏。C++ 被破坏了，非常奇怪。符号名称中不允许使用某些字符，如:或。,编译这个 C++ 源代码：

namespace myspace { void myfunc() {} }

我们看到输出：

...
0000000000000000 T __ZN7myspace6myfuncEv
...

并且主方法名称永远不会被破坏。如果我们有这样的：

int main(int argc, char** argv) {}
int main(std::vector<std::string> args) {}

只有第二个名字被破坏了。我想这可能就是问题所在。而且，这些警告毫无意义。它们意味着系统是用低调试符号计数重新编译的。