我如何得到一个自制的版本的GDB工作在Mac OS X？ [英] How do I get a homebrewed version of GDB working on Mac OS X?

问题描述

我想使用gdb在Eclipse中调试一个C ++程序。我认为它在我的 main（）函数工作正常，但在其他地方它给我一个警告，当我尝试看一个变量的值：

无法执行MI命令：
-data-evaluate-expression变量
来自调试器的错误消息后端：
找不到Class :: method（）的框架基础。`


，我很难理解这个错误的意思，或找出如何解决这个问题。还有一些其他类似的问题（此处和此处）浮动在堆栈溢出。

由于苹果的Xcode命令行工具很痛苦地过时了（参见 gcc 和 gdb 问题）我需要使用自己的自制版本。我不知道这些工具的安装是否有一些我可能错过了。

我可以从命令行使用gdb调试，我碰到相同的错误：找不到Class :: method（）的框架基础，所以我很确定这不是Eclipse的问题。

$

有没有什么跳出来给任何人，这可能会导致这个问题？Mac OS X 10.8 .5（Mountain Lion）


• Eclipse 4.2.1（Juno）


• gcc 4.8.2（自制） -Oh 和 -g3 ）


• gdb 7.6.2（自制和代码签名）

更新：

  BFD：/System/Library/Frameworks/CFNetwork.framework/Versions/A/CFNetwork(i386:x86-64）：未知加载命令0x20 
  

其后出现几个警告：

 警告：无法打开OSO存档文件/private/tmp/gcc48-KqoQ/gcc-4.8.2/build/x86_64-apple-darwin12.5.0/libstdc++-v3/ src /../ libsupc ++ /。libs / libsupc ++ convenience.a
警告：无法打开OSO存档文件/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
警告：无法打开OSO归档文件/ 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打开以读取符号：没有这样的文件或目录。 
 warning：`/private/tmp/gcc48-KqoQ/gcc-4.8.2/build/x86_64-apple-darwin12.5.0/libstdc++v3/src/.libs/compatibility-c++0x.o' ：无法打开读取符号：没有这样的文件或目录。 
 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打开以读取符号：没有这样的文件或目录。 
 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'：无法打开读取符号：没有这样的文件或目录。 
 ... 
  

谷歌搜索gdb bfd未知加载命令显示很多网站没有任何解决方案，但他们似乎都表明，非苹果版本的gdb和Mac OS X 10.8 +之间可能会有冲突。

任何洞察力都会帮助一吨！

解决方案

名称与GCC和Clang相同（它们通常共享类似的机制）。名称调整使其可用于具有相同名称的C / C ++方法和装配过程。看看C定义会发生什么：

  void myfunc（）{} 
  / pre> 
 
 
我们使用 nm 来查看符号的二进制名称。使用 nm --demangle 可查看未解析的名称。编译文件的Nm输出是：
 ... 
 0000000000000000 T _myfunc 
 ... 
其他符号数取决于调试级别，请参阅GCC联机帮助页-O和-g选项。正如我们看到的，有一个数字。它是十六进制。它在32位机器上有8位数，在64位机器上有16位数（这是因为n位CPU意味着n位代表一个指针，符号实际上是二进制文件中的一个指针）。然后我们有符号类型。现在只有两个值很有趣： T 是一个C / C ++ / ...方法， t 是一个汇编程序。如果我们编译以下汇编代码，看看会发生什么：
  myproc：
  pre> 
 
 
在编译汇编时，GCC和Clang不应该推送调试符号，因此 nm 输出可能看起来像： 
  0000000000000000 t myproc 
  
 
 b $ b 
装配过程名称不会被破坏。 C ++是非常奇怪的。在符号名称中不允许使用某些字符，例如：或，。编译此C ++源代码：
 命名空间myspace {void myfunc（）{}} 
  
我们看到输出：
  ... 
 0000000000000000 T __ZN7myspace6myfuncEv 
 ... 
  
而且主要方法名称从不被复制。如果我们有这样的：
  int main（int argc，char ** argv）{} 
 int main std :: vector< std :: string> args）{} 
  
我认为这可能是问题。而且，这些警告意味着没有。它们意味着系统以低调试符号计数重新编译。
 
I am trying to debug a C++ program in Eclipse using gdb. I think it works fine in my main() function, but elsewhere it gives me a warning when I try to look at the value of a variable:
Failed to execute MI command:
-data-evaluate-expression variable
Error message from debugger back end:
Could not find the frame base for "Class::method()".`
After scouring the internet, I am having a hard time understanding what this error means or finding out how to fix the problem. There are a few other similar questions (here and here) floating around Stack Overflow.

Since Apple's Xcode command line tools are painfully out-of-date (see gcc and gdb issues) I needed to use my own homebrewed versions. I don't know if there is something in the setup for these tools that I might have missed.

I can debug from command line using gdb and I hit the same error: "Could not find the frame base for "Class::method()", so I'm pretty sure it is not an issue with Eclipse.

Does anything jump out to anyone, that might be causing this problem?


Mac OS X 10.8.5 (Mountain Lion)
Eclipse 4.2.1 (Juno)
gcc 4.8.2 (homebrewed) (with -O0 and -g3)
gdb 7.6.2 (homebrewed and codesigned)


Update:

I am also seeing the line:
BFD: /System/Library/Frameworks/CFNetwork.framework/Versions/A/CFNetwork(i386:x86-64): unknown load command 0x20
Followed by several warnings:
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.
...
which continues for several lines. Google searches for "gdb bfd unknown load command" reveal a lot of sites without any solution, but they all seem to indicate that there may be a conflict between non-apple versions of gdb and Mac OS X 10.8+.

Any insight would help a ton!
解决方案
It's because the name mangling. Names are mangled same with GCC and Clang (they often share similar mechanisms). Name mangling makes it available to have C/C++ method and Assembly procedure with the same name. See what happens to a C definition:
void myfunc() {}
We use nm to view binary names of symbols. Use nm --demangle to view unmangled names. Nm output for compiled file is:
    ...
    0000000000000000 T _myfunc
    ...
Number of other symbols depends on debugging level, see GCC manpage for -O and -g options. As we see, there is a number. It's hexadecimal. It has eight digits on 32bit machines and sixteen digits on 64bit machines (it's because n-bit CPU means that n-bits represent a pointer, the symbol is really a pointer inside the binary file). Then we have symbol type. Only two values are interesting now: T is a C/C++/... method, t is an assembler procedure. See what goes on if we compile following assembly code:
myproc:
GCC and Clang shouldn't push debugging symbols when compiling Assembly, so nm output will probably look like:
0000000000000000 t myproc
Assembly procedure names are not mangled. C++ is mangled, very strangely. Some characters, like : or , are not allowed in symbol name. Compile this C++ source:
namespace myspace { void myfunc() {} }
We see output:
...
0000000000000000 T __ZN7myspace6myfuncEv
...
And main method name is never mangled. If we have like this:
int main(int argc, char** argv) {}
int main(std::vector<std::string> args) {}
only the second name is mangled. I think this may be the problem. And, these warnings mean NOTHING. They mean that system was recompiled with low debugging symbol count.

                        
这篇关于我如何得到一个自制的版本的GDB工作在Mac OS X？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！