Was sind effiziente Möglichkeiten zum Debuggen eines optimierten C/C++-Programms?

Question

Oft arbeite ich mit optimiertem Code (manchmal sogar mit vektorisierten Schleifen), der Fehler usw. enthält.Wie würde man solchen Code debuggen?Ich bin auf der Suche nach Werkzeugen oder Techniken jeglicher Art.Ich verwende die folgenden (möglicherweise veralteten) Tools und möchte daher ein Upgrade durchführen.

Ich verwende Folgendes:

• Da Sie mit ddd den Code nicht sehen können, verwende ich den Befehl gdb+ dissambler und sehe den erzeugten Code;Damit komme ich nicht wirklich durch das Programm.
• ndisasm

Danke

Answer 1

Es ist immer schwieriger, optimierte Programme zu debuggen, aber es gibt immer Möglichkeiten. Einige zusätzliche Tipps:

• Machen Sie einen Debug -Build und prüfen Sie, ob Sie in einem Debug -Build den gleichen Fehler erhalten. Es macht keinen Punkt, eine optimierte Version zu debuggen, wenn Sie nicht müssen.
• Verwenden Sie Valgrind, wenn es auf einer Plattform ist, die es unterstützt. Die Fehler, die Sie sehen, sind möglicherweise schwerer zu verstehen, aber das Problem frühzeitig vereinfacht das Debuggen häufig.
• Das Printf -Debugging ist primitiv, aber manchmal ist es der einfachste Weg, wenn Sie ein komplexes Problem haben, das nur in optimierten Builds angezeigt wird.
• Wenn Sie ein Timing -Problem vermuten (insbesondere in einem Multithread -Programm), rollen Sie Ihre eigene Version von Assert, die abbricht oder druckt, wenn die Bedingung verletzt wird, und verwenden Sie es an einigen ausgewählten Stellen, um mögliche Probleme auszuschließen.
• Sehen Sie, ob Sie das Problem reproduzieren können, ohne -Fomit -Frame -Pointers zu verwenden, da der Code sehr schwer zu debuggen und mit -O2 oder -O3 aktiviert ist. Das kann Ihnen genügend Informationen geben, um die Ursache Ihres Problems zu finden.
• Isolieren Sie Teile Ihres Codes, erstellen Sie einen Test-Suite und prüfen Sie, ob Sie alle fehlenden Tests identifizieren können. Es ist viel einfacher, eine Funktion zu debuggen als das gesamte Programm.
• Versuchen Sie, die Optimierungen nacheinander mit den Optionen -fno -X -Optionen auszuschalten. Dies kann Ihnen helfen, häufige Probleme wie strenge Aliasing -Probleme zu finden.
• Schalten Sie mehr Compiler -Warnungen ein. Einige Dinge, wie strenge Aliasing -Probleme, können Compiler -Warnungen erzeugen, wenn sie einen Unterschied im Verhalten zwischen verschiedenen Optimierungsniveaus schaffen.

Answer 2

Beim Debuggen von Release-Builds können Sie __asm ​​nops;als Platzhalter für Haltepunkte (int 3).Das ist praktisch, da Sie Haltepunktpositionen garantieren können, ohne Compiler-Optimierungen durcheinander zu bringen oder printf/cout-Anweisungen zu schreiben.

Answer 3

Es ist natürlich immer einfacher, eine nicht optimierte Version zu debuggen. Wenn dies nicht der Fall ist, kann die Demontage des Codes hilfreich sein. Andere Techinques, die ich verwendet habe, umfassen teilweise deoptimiert, indem die Intermediate-Ergebnisse gedruckt oder protokolliert werden oder eine kritische Variable in "volatil" geändert werden können, damit ich zumindest einsehen kann das Wert im Debugger.

Answer 4

Die Chancen stehen gut, dass Sie einen optimierten Code bezeichnen, der sich in Rasurzyklen befindet (was das Debuggen schwierig macht), ist jedoch nicht wirklich sehr optimiert. Hier ist ein Beispiel für das, was ich meine.

Ich würde die Compiler -Optimierung ausschalten, selbst debuggen und selbst einstellen und dann die Compiler -Optimierung wieder einschalten, wenn der Code Hotspots enthält, die tatsächlich in Code sind, den der Compiler sieht (nicht in externen Bibliotheken). (Ich definiere einen Hotspot als Teil des Codes, in dem der PC häufig gefunden wird. Das befreit Schaufen, die Funktionsaufrufe enthalten, weil sie den PC wegstehlen.)