How do I debug C++0x programs in MacPorts gcc 4.5?_问答_开发者

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 the debug symbols for my executable either.

I am on OSX 10.5.8, with macports, and I compile my code with

g++-mp-4.5 -Wall -pedantic -std=c++0x -g -ggdb -I/opt/local/include -L/opt/local/lib -lgsl -static-libstdc++ MCMC-simplex.cpp -o mcmc

(there is only one file, and g++-mp-4.5 is the macports executable for gcc/g++ 4.5 )

When I try running gdb on the resulting executable, I get many error messages (at startup) of the form

warning: Could not find object file "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_gcc45/work/build/i386-apple-darwin9/libgcc/trunctfdf2_s.o" - no debug information available for "../../../gcc-4.5.0/libgcc/../gcc/config/soft-fp/trunctfdf2.c".

which to me indicates that macports has a bug during its build (it seems like gdb is looking for the object files in the temporary build directory).

I should add that when I try to see my programs listing in gdb (the one provided by Apple), it tries to look for a random .s file in /var/tmp, which to me sounds like an assembler file. That is why I say it does not seem able to find the debug symbols for my program either.

When I try MacPorts gdb 7.1, I get

warning: `/var/folders/Xa/Xaq开发者_JAVA百科HO9PeEC8K-Nrd0L9xWk+++TM/-Tmp-//cc2IvFto.o': can't open to read symbols: No such file or directory. (no debugging symbols found)...done.

and none of the many error messages that Apple's gdb gives out (although the end result is the same).

Has anyone come across this problem, and came up with a solution?

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:

Create assembly file /tmp/[random-string].s
Assemble it into /tmp/[random-string].o
Link /tmp/[random-string].o with crt0.o, libc, etc. into mcmc executable.
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.

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

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.