LLDB zeigt keinen Quellcode

Question

Ich versuche, ein C++ - Programm zu debuggen, das ich schreibe, aber wenn ich es in LLDB starte und das Programm stoppe, zeigt es mir nur den Assembler, nicht die Originalquelle. z.B. nach dem Absturz versuche ich zu debuggen:

Process 86122 stopped 
* thread #13: tid = 0x142181, 0x0000000100006ec1 debug_build`game::update() + 10961, stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT) 
    frame #0: 0x0000000100006ec1 debug_build`game::update() + 10961 
debug_build`game::update: 
-> 0x100006ec1 <+10961>: movq (%rdx), %rdx 
    0x100006ec4 <+10964>: movq %rax, -0xb28(%rbp) 
    0x100006ecb <+10971>: movq -0x1130(%rbp), %rax 
    0x100006ed2 <+10978>: movq 0x8(%rax), %rsi 

ich mit -O0 -g bin kompilieren. Ich sehe dasselbe, wenn ich den Debugger über Xcode (ich bin auf OSX) oder von der Kommandozeile aus laufe.

Was muss ich noch tun, um den Quellcode in LLDB anzeigen zu lassen?

Zusätzliche Hinweise

Hier ist ein Beispiel eines typischen Build-Befehl:

clang++ -std=c++1y -stdlib=libc++ -fexceptions -I/usr/local/include -c -O2 -Wall -ferror-limit=5 -g -O0 -ftrapv lib/format.cpp -o format.o 

Je früher -O2 ist es, weil das ist der Standard ich verwende, aber ich glaube, die später -O0 Überschreibungen es richtig?

Was ich versucht habe

1. ich dieses Problem mit einem einfachen neu erstellt habe ‚Hallo Welt‘ Programm der gleichen Build-Einstellungen.

2. Nach einigem Suchen habe ich versucht, dsymutil main.o laufen zu lassen, der warning: no debug symbols in executable (-arch x86_64) sagte, also werden die debug Symbole möglicherweise nicht von meinen Erstellungsbefehlen erzeugt?

3. Ich habe auch versucht, -gsplit-dwarf zu den Build-Befehlen hinzuzufügen, aber ohne Wirkung.

4. Hier ist der Link-Befehl von meiner 'Hallo Welt' Version:

   Klirren ++ main.o -L/usr/local/lib -g -o hallo

5. Ich lief dwarfdump (I read about it here) auf die ausführbaren Dateien und Objektdateien. Es sieht für mein ungeübtes Auge wie die Debug-Symbole sind in den Objektdateien vorhanden, aber nicht in der ausführbaren Datei selbst (es sei denn, dwarfdump funktioniert nur auf Objektdateien, was möglich ist). Vielleicht ist die Verknüpfungsstufe das Problem. Oder vielleicht gibt es ein Problem mit dem DWARF.

6. Ich habe jetzt funktioniert dies in der 'Hallo Welt' Programm, durch die Ausgabe von Build-Befehle eins nach dem anderen im Terminal. Ich vermute daher, dass dies ein Problem mit meinem Build-System sein könnte (Tup), möglicherweise die Befehle mit einem anderen Arbeitsverzeichnis, so dass die Pfade gemangled oder so etwas.

Answer 1

Wenn Sie die -g Befehlszeilenoption hinzufügen, in der .o Datei klirren, wird DWARF Debug-Informationen setzen. Wenn Sie Ihre Objektdateien (.o, ralib Archiv alias statische Bibliotheken alias .a Dateien) in eine ausführbare Datei/dylib/framework/bundle verknüpfen, werden "Debug Notes" in die ausführbare Datei geschrieben, um (1) den Speicherort der .o usw. Dateien mit anzugeben die Debug-Informationen und (2) die endgültigen Adressen der Funktionen/Variablen in der ausführbaren Binärdatei.Optimierungsflags (-O0, -O2 usw.) haben keinen Einfluss auf die Generierung von Debuginformationen - obwohl Debugcode, der mit der Optimierung kompiliert wird, viel schwieriger ist als der Debugcode, der unter -O0 erstellt wurde.

Wenn Sie den Debugger an diesem ausführbaren Binärdatei ausführen - ohne weitere Modifikation - der Debugger die Debug-Informationen aus den .o etc Dateien so lange lesen, da sie noch auf dem Dateisystem auf dem gleichen Dateipfad sind wenn Sie die ausführbare Datei erstellt haben. Dies macht die iterative Entwicklung schnell - kein Werkzeug muss die (großen) Debug-Informationen lesen, aktualisieren und ausgeben. Sie können diese "Debug-Notizen" in der ausführbaren Datei durch Ausführen von und Suchen nach OSO Einträge (unter anderem) sehen. Dies sind sticks nlist Einträge und Ausführen strip(1) auf Ihrer ausführbaren Datei wird sie entfernen.

Wenn Sie alle Debuginformationen (in den .o-Dateien) in einem eigenständigen Paket sammeln möchten, führen Sie dsymutil auf der ausführbaren Datei aus. Dies verwendet die Debug-Notizen (Annahmen: (1) die .o Dateien sind immer noch an ihrem ursprünglichen Speicherort und (2) die ausführbare Datei wurde nicht entfernt), um ein "dSYM Bundle" zu erstellen. Wenn die Binärzahl exename ist, ist das dSYM-Bundle exename.dSYM. Wenn der Debugger unter exename ausgeführt wird, wird es neben dieser Binärdatei für das dSYM-Bundle aussehen. Wenn es dort nicht gefunden wird, führt es eine Spotlight-Suche durch, um festzustellen, ob sich der dSYM an einem Spotlight-indizierten Ort auf Ihrem Computer befindet.

Sie können dwarfdump auf .o Dateien oder auf dem dSYM-Bundle ausführen - beide haben Debug-Informationen in ihnen. dwarfdump findet keine Debug-Informationen in der ausführbaren Ausgabedatei.

So, der normale Workflow: Kompilieren Sie mit -g. Link ausführbares Bild. Wenn iterative Entwicklung, Debugger ausführen. Wenn Sie die Binärdatei versenden/archivieren, erstellen Sie dSYM, strip executable.

Answer 2

Ich löste es durch Hinzufügen des Pfades zu Debug-Symbolen, die in a.out.dSYM Verzeichnis mit (lldb) target symbols add a.out.dSYM Befehl vorhanden sind.