How do I debug C++0x programs in MacPorts gcc 4.5?

Question

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 th

Answer 1

Well, another "trick" to keep going with a single compile-and-link step would be to add
-save-temps=obj
to your g++ command line so that

4 Remove /tmp/[random-string].o and .s

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

Answer 2

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:

strings - libsomething.dylib | grep something.o

Note that you need the '-' (this got me the first time).

To fix it, strip debugging info like so:

strip -S libsomething.dylib

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.

Answer 3

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:

1. Create assembly file /tmp/[random-string].s
2. Assemble it into /tmp/[random-string].o
3. Link /tmp/[random-string].o with crt0.o, libc, etc. into mcmc executable.
4. Remove /tmp/[random-string].o and .s

It is that last step which prevents you from debugging.

Solution:

g++-mp-4.5 -Wall -pedantic -std=c++0x -g -ggdb -c MCMC-simplex.cpp
g++-mp-4.5 MCMC-simplex.o -lgsl -static-libstdc++ -o mcmc

This will leave MCMC-simplex.o in the current directory, and will allow GDB to find debug info in it.