¿Cómo puedo depurar programas C++ 0x en MacPorts gcc 4.5?

Question

Tengo un programa simple de C++ Estoy tratando de depurar, pero gdb no puede encontrar el archivo objeto para las bibliotecas (o no hay información de depuración disponible), y tampoco parece poder encontrar los símbolos de depuración para mi ejecutable.

estoy en OSX 10.5.8, con macports, y compilo mi código con

g ++ - mp-4,5 -Wall -pedantic -std = C++ 0x -g -ggdb -I/optar/local/incluir -L/opt/local/lib -lgsl -static-libstdC++ MCMC-simplex.cpp -o MCMC

(sólo hay un archivo, y g ++ - mp-4,5 es el macports ejecutable para gcc/g ++ 4.5)

Cuando intento ejecutar gdb en el ejecutable resultante, recibo muchos mensajes de error (en inicio) de la forma

advertencia: No se pudo encontrar /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 de fichero objeto". o "- no hay información de depuración disponible para" ../../../gcc-4.5.0/libgcc/../gcc/config/soft-fp/trunctfdf2.c ".

que me indica que macports tiene un error durante su compilación (parece que gdb está buscando los archivos de objeto en el directorio de compilación temporal).

debo añadir que cuando trato de ver mis programas de inclusión en GDB (el proporcionado por Apple), que trata de buscar un archivo aleatorio .s en /var/tmp, que me suena como un archivo de ensamblador. Es por eso que digo que tampoco parece poder encontrar los símbolos de depuración para mi programa.

Cuando intento DarwinPorts GDB 7.1, recibo

advertencia: `/var/folders/Xa/XaqHO9PeEC8K-Nrd0L9xWk+++TM/-Tmp-//cc2IvFto.o ': no ​​se puede abierto para leer símbolos: no existe dicho archivo o directorio. (no se encontraron símbolos de depuración) ... hecho.

y ninguno de los muchos mensajes de error que da el gdb de Apple (aunque el resultado final es el mismo).

¿Alguien ha encontrado este problema y ha encontrado una solución?

Answer 1

Bueno, otro "truco" para seguir adelante con un solo paso de compilación y enlace sería añadir
-save-temps=obj
a su g línea de comandos ++ para que

4 de Eliminar/tmp/[ random-string] .oy .S

es en realidad una especie de no realizarse (en realidad al final tener los archivos canónicos SOURCE.o y SOURCE.s en el directorio donde se está construyendo en lugar de aL aZAR-sTRING . [os] en algunas carpetas temporales, pero desde el punto de vista de localizar símbolos de depuración que está bien

Answer 2

A diferencia de otros UNIXen, en MacOS, la información de depuración no está vinculada al ejecutable. En su lugar, el ejecutable tiene una lista de archivos de objeto que estaban vinculados a él, y el depurador busca información de depuración en estos archivos de objetos individuales.

Si elimina los archivos del objeto, entonces no puede depurar.

Al compilar y enlazar el ejecutable en "un solo paso", GCC hace esto:

1. Crear archivo de ensamblaje /tmp/[random-string].s
2. Montar en /tmp/[random-string].o
3. Enlace /tmp/[random-string].o con crt0.o, libc, etc. en el ejecutable mcmc.
4. Retire /tmp/[random-string].o y .s

Es el último paso que le impide la depuración.

Solución:

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 

Esto dejará MCMC-simplex.o en el directorio actual, y permitirá que el BGF para encontrar la información de depuración en el mismo.

Answer 3

Me parece que tiene dos problemas: 1) sin símbolos de depuración para el ejecutable y 2) sin símbolos de depuración para algunas bibliotecas compartidas que generaron advertencias. Yo también tenía el problema 2). El ruso empleado respondió 1) y me indicó la dirección correcta para 2).

Primero, si no necesita depurar las bibliotecas mencionadas en las advertencias, se pueden ignorar de forma segura. Pero, por supuesto, las advertencias son molestas y podrían ocultar otros problemas. En su caso y el mío, las bibliotecas instaladas por MacPorts deberían haber eliminado los símbolos de depuración, pero no lo hicieron. El motivo que causa una advertencia es, como dice Russian empleado, porque los símbolos en sí mismos se guardan en archivos de objeto generados durante el proceso de compilación y no en las bibliotecas instaladas. Las bibliotecas almacenan punteros a los archivos de objeto como parte de su información de depuración (mínima).

Puede verificar esto con el comando strings. Si eres gettings advertencias que /crazy/path/to/something.o no se puede encontrar al cargar libsomething.dylib:

strings - libsomething.dylib | grep something.o 

en cuenta que necesita el '-' (esto me consiguió la primera vez)

solucionarlo, tira de información de depuración, así:

strip -S libsomething.dylib 

Posteriormente, 'dwarfdump libsomething.dylib --file-estadísticas' debe demostrar que la "depuración puñaladas" sección está vacía. (Los enlaces a los archivos de objeto se almacenan en formato de depuración STABS.)

No más advertencias feas ... ¡yay!

Eso fue manera demasiado difícil.