How do I get a homebrewed version of GDB working on Mac OS X?

Question

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!

Answer 1

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.