Eclipse CDT Multithread-Debugging nicht optimal – wie führt man Threads ausschließlich aus?

Ich kenne die Antwort darauf, ich stelle sie hier hoch, damit andere sie sehen können

Wenn Sie Eclipse CDT verwenden, verstehen Sie wahrscheinlich, dass Eclipse kein Debugger ist, sondern nur ein Anwendungs-Frontend, speziell für GDB. Wenn Sie also C++-Programme debuggen, verwenden Sie GDB eigentlich nur auf komfortablere Weise. Wenn Sie jemals ein Multithread-Programm in Eclipse CDT debuggen müssen, werden Sie feststellen, dass es schnell hektisch wird, denn wenn Sie einen Haltepunkt erreichen, stoppen alle Threads, und wenn man versucht, eine einzelne Zeile in einem bestimmten Thread auszuführen, wird es auch ausgeführt die anderen Fäden. Damit es richtig funktioniert, müssen die Threads willkürlich und ausschließlich ausgeführt werden können – so dass der Programmierer, wenn er eine einzelne Zeile ausführt, nur den spezifischen Thread ausführt.

Daher lassen die Einstellungen von gdb standardmäßig die “Scheduler-Sperre” deaktiviert. Wenn Sie Multithread-Anwendungen debuggen, werden Sie verstehen, dass dies in GDB aktiviert sein muss, damit das gewünschte Verhalten erreicht wird. Wie führt man diesen Befehl aus:

set scheduler-locking on

in GDB innerhalb von Eclipse CDT?

Zumindest eine Möglichkeit, die das Problem sicherlich löst, besteht darin, zu wissen, wie man durch die immense Menge an Funktionen navigiert, die Eclipse bietet. Wenn ein Programm gestartet wird, wechselt Eclipse CDT normalerweise das Konsolenfenster (wenn Sie es geöffnet haben, ist es normalerweise unten), um die Eingabe/Ausgabe des Programms anzuzeigen.

Aber Sie können dies ändern, wenn Sie dies nicht wussten Bild. Mit dem Knopf vorletzter rechts – dem blauen, der wie ein Monitor aussieht – können Sie die GDB-Eingabekonsole auswählen. Es wurde auch in diesem Thread diskutiert.

Von dort aus geben Sie einfach den Befehl ein.

GELÖST, BRAUCHEN ABER EINE BESSERE LÖSUNG

Aber jetzt, da dies gelöst wurde, um es der Bequemlichkeit halber besser zu lösen; set scheduler-locking on jedes Mal eingeben zu müssen, wenn ein Programm startet, ist albern. Das Problem beim Laden einer gdbinit-Datei besteht jedoch darin, dass die gdbinit-Datei bezogen wird, bevor Eclipse das Programm für gdb zum Lösen eingestellt hat. Dies ist ein Problem, da es dazu führt, dass die Debugger-Ansicht in Eclipse hängen bleibt, wie sich gdb beschwert. Um zu verstehen, was passiert, versuchen Sie, gdb zu starten, und geben Sie dann den Befehl ein, ohne eine auszuführende Binärdatei zu laden. Es schlägt fehl. Wie stellt man dies als Option ein, die klebrig ist?

Vielleicht, wenn Sie das folgende gdb-Skript hinzufügen, das die Variable setzen könnte, wenn das Programm stoppt, und es ausschaltet, wenn Sie fortfahren:

define hook-step
set scheduler-locking on
end
define hookpost-step
set scheduler-locking off
end
define hook-run
set scheduler-locking off
end
define hook-continue
set scheduler-locking off
end

Meine Antwort leitet sich von der von @user1448557 ab. Leider habe ich derzeit nicht genug Reputation, um es zu kommentieren (oder es übrigens hochzustimmen). Die Strategie scheint großartig zu sein, aber die Antwort könnte etwas veraltet sein, da es nicht um “Scheduler-Sperrschritt festlegen” geht. Ich habe Folgendes in meine gdb-Initialisierungsdatei (innerhalb meines Eclipse-Projekts) eingefügt und es tut, was ich will.

#inspired from [link to this thread][1]
define hookpost-run
set scheduler-locking step
end

In Bezug auf den Kommentar von @rbaleksandar erlauben Eclipse CDT-Startkonfigurationen die Angabe einer “GDB-Befehlsdatei”, und der Standardwert ist normalerweise .gdbinit