Ich habe ein einfaches C ++ - Programm, das ich zu debuggen versuche, aber gdb kann die Objektdatei für die Bibliotheken nicht finden (oder es sind keine Debug-Informationen verfügbar), und es scheint auch die Debug-Symbole für meine ausführbare Datei nicht zu finden.
Ich bin auf OSX 10.5.8, mit Macports, und kompiliere meinen Code mit
g ++ - mp-4.5 -Wand -pedantisch -std = c ++ 0x -g -ggdb -I / opt / lokal / include -L / opt / local / lib-lgsl -static-libstdc ++ MCMC-simplex.cpp -o mcmc
(es gibt nur eine Datei und g ++ - mp-4.5 ist die ausführbare Macports-Datei für gcc / g ++ 4.5)
Wenn ich versuche, gdb auf der resultierenden ausführbaren Datei auszuführen, erhalte ich viele Fehlermeldungen (beim Start) des Formulars
Warnung: Objektdatei konnte nicht gefunden werden "/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" - keine Debuginformationen verfügbar für "../../../ gcc-4.5.0 / libgcc / ../ gcc / config / soft-fp / trunctfdf2.c".
was für mich bedeutet, dass Macports während des Builds einen Fehler hat (es sieht so aus, als würde gdb nach den Objektdateien im temporären Build-Verzeichnis suchen).
Ich sollte hinzufügen, dass wenn ich versuche, meine Programme in gdb (die von Apple zur Verfügung gestellt) zu sehen, versucht es nach einer zufälligen .s Datei in /var/tmp zu suchen, was für mich klingt wie eine Assembler-Datei. Deshalb sage ich, dass es nicht in der Lage scheint, die Debug-Symbole für mein Programm zu finden.
Wenn ich MacPorts 7.1 ausprobieren, bekomme ich
Warnung: '/var/folders/Xa/XaqHO9PeEC8K-Nrd0L9xWk+++TM/-Tmp-//cc2IvFto.o': kann nicht geöffnet werden, um Symbole zu lesen: Keine solche Datei oder Verzeichnis. (keine Debugging-Symbole gefunden) ... fertig.
und keine der vielen Fehlermeldungen, die Apples gdb gibt (obwohl das Endergebnis das gleiche ist).
Ist jemand auf dieses Problem gestoßen und hat eine Lösung gefunden?
Nun, ein weiterer "Trick", um mit einem einzigen Compile-and-Link-Schritt weiterzumachen, wäre das Hinzufügen von
-save-temps=obj
an Ihre g ++ - Befehlszeile, so dass
4 Entfernen Sie /tmp/[random-string].o und .s
wird tatsächlich nicht ausgeführt (tatsächlich haben Sie am Ende die kanonischen Dateien SOURCE.o und SOURCE.s in dem Verzeichnis, in dem Sie bauen, statt RANDOM-STRING. [os] in einigen temporären Ordnern, aber von der Point of View der Fehlersuche Symbole zu finden, das ist in Ordnung
Im Gegensatz zu anderen UNIXen ist die Debug-Information auf MacOS nicht mit der ausführbaren Datei verknüpft. Stattdessen verfügt die ausführbare Datei über eine Liste von Objektdateien, die darin verknüpft sind, und der Debugger sucht nach Debuginformationen in diesen einzelnen Objektdateien.
Wenn Sie die Objektdateien entfernen, können Sie nicht debuggen.
Wenn Sie die ausführbare Datei in "single step" kompilieren und verknüpfen, führt GCC das aus:
/tmp/[random-string].s
/tmp/[random-string].o
/tmp/[random-string].o mit crt0.o , libc usw. mit mcmc executable. /tmp/[random-string].o und .s
Es ist der letzte Schritt, der Sie daran hindert, zu debuggen.
Lösung:
%Vor% Damit bleibt MCMC-simplex.o im aktuellen Verzeichnis und GDB kann darin Debug-Informationen finden.
Es scheint mir, dass Sie zwei Probleme hatten: 1) keine Debug-Symbole für ausführbare Dateien und 2) keine Debug-Symbole für einige gemeinsam genutzte Bibliotheken, die Warnungen generiert haben. Ich hatte auch ein Problem 2). Angestellter Russe antwortete 1) und wies mich in die richtige Richtung für 2).
Erstens, wenn Sie die in den Warnungen erwähnten Bibliotheken nicht debuggen müssen, können sie sicher ignoriert werden. Aber natürlich sind die Warnungen nervig und könnten andere Probleme verbergen. In Ihrem und meinem Fall sollten die von MacPorts installierten Bibliotheken Debug-Symbole entfernt haben, dies aber nicht. Der Grund, der eine Warnung verursacht, ist, wie Employed Russian sagt, weil die Symbole selbst in Objektdateien gehalten werden, die während des Buildprozesses und nicht in den installierten Bibliotheken generiert werden. Die Bibliotheken speichern Zeiger auf die Objektdateien als Teil ihrer (minimalen) Debug-Informationen.
Sie können dies mit dem Befehl strings überprüfen. Wenn Sie Warnungen bekommen, dass /crazy/path/to/something.o beim Laden von libsomething.dylib nicht gefunden werden kann:
%Vor%Beachten Sie, dass Sie das '-' brauchen (das hat mich das erste Mal bekommen).
Um es zu beheben, entfernen Sie Debug-Informationen wie folgt:
%Vor%Danach sollte 'dwarfdump --file-stats libsomething.dylib' zeigen, dass der Abschnitt "STABS debug" leer ist. (Die Links zu Objektdateien werden im STABS-Debug-Format gespeichert.)
Keine hässlichen Warnungen mehr ... yay!
Das war Weise zu schwer.
Tags und Links gcc c++11 macports gdb debug-symbols