Weiter Zurück Inhaltsverzeichnis

### 12. Der interne Debugger

### 12.1 Einstellungen

Standardmäßig verwendet KDevelop den internen Debugger. Dies kann unter "Einstellungen" geändert werden. Wählen Sie "KDevelop setup" und dann "Debugger" .

Aktivieren Sie das Kontrollkästchen "Verwende externen Debugger", wenn Sie einen anderen Debugger verwenden wollen und geben Sie den Namen des externen Debuggers ein. Zur Bedienung Ihres Debuggers konsultieren Sie bitte die entsprechende Dokumentation.

Bei Auswahl des internen Debuggers erhalten Sie eine Anzahl zusätzlicher Optionen aus denen Sie auswählen können:

- Zeige static members: Die Anzeige von statischen Elementen verlangsamt gdb bei der Datenenerzeugung in kde und qt. Die "Signatur" der Daten auf die sich QString und friend-Funktionen verlassen, könnte verändert werden. Wenn Sie jedoch diese Werte debuggen müssen, markieren Sie die Option
- Zeige Teil-Namen an: Bei der Anzeige von disassembliertem Code können Sie sich Teil-Namen der Methoden anzeigen lassen. Vollständige Namen sind jedoch einfacher zu lesen.
- BPs beim Laden von Bibliotheken setzen: Hiermit wird versucht "schwebende" Breakpoints beim Laden von Bibliotheken zu setzen. Wenn GDB eine Bibliothek die mittels "dlopen" geladen werden soll noch nicht kennt, weigert er sich Unterbrechungen in diesem Code anzunehmen. Es ist jedoch möglich beim Laden der Bibliothek anzuhalten und dann zu versuchen die "schwebenden" Breakpunkte zu setzen. Im Kapitel Dynamische Bibliotheken und Unterbrechungen finden Sie Details und Probleme dieser Vorgehensweise. Wenn Sie keine Bibliotheken mit "dlopen" öffnen, lassen Sie diese Option ausgeschaltet.
- Schwebende Werkzeugleiste: Dies erlaubt Ihnen zusätzlich die Steuerung des Debuggers mit Hilfe der schwebenden Werkzeugleiste. Die Werkzeugleiste ist bestens zum Debuggen von GUI Anwendungen geeignet. Details finden Sie unter Die schwebende Werkzeugleiste.
- Separates Terminal für Anwendungs I/O einschalten: Dies ermöglicht Ihnen, Terminaleingaben zu machen, wenn Ihre Anwendung Terminaleingabecode enthält (z.B. cin, fgets etc.). Wenn Ihre Anwendung solchen Code enthält, wählen Sie diese Option, sonst lassen Sie sie ausgeschaltet. Tip: Diese Option wird am sinnvollsten zusammen mit der schwebenden Werkzeugleiste eingesetzt, da so das Terminalfenster nicht vom KDevelopfenster verdeckt wird, wenn Sie den Debugger bedienen.

### 12.2 Verwendung des internen Debuggers

#### Änderungen in den Baum- und Ausgabeansichten

Bei Verwendung des internen Debuggers werden den Baum- und Ausgabeansichten drei Tabs hinzugefügt.

#### In der Baumansicht

- VAR Tab : Eine Baumansicht der lokalen Variablen des aktuellen Stackframes. Es können auch Variablen der aufrufenden Funktion angezeigt werden. Außerdem enthält dieses TAb ein Watch Fenster. Dies ermöglicht es globale Variablen anzuzeigen; oder Sie wollen vielleicht nur eine lokale Variable anzeigen anstatt sie in einer langen Liste lokaler Variablen zu suchen.

#### In der Ausgabeansicht

- Breakpoint : Eine Liste der aktuell gesetzten Unterbrechungen und ihr aktueller Status.
- Framestack : Eine Liste der zur Zeit aufgerufenen Funktionen
- Disassemble : Eine Ansicht des Assemblercodes der aktuell ausgeführten Anweisung

#### Änderungen im Debugmenü und im Panel

#### Im Panel

Ihnen stehen zwei normale und zwei Dropdown-Knöpfe zur Verfügung, sobald Sie den Debugger starten.

#### Im Debugmenü

Wenn Sie den Debugger starten, werden die zehn Einträge zu Steuerung des Debuggers eingeschaltet.

Verfügbare Funktionen:

- Ausführen: Fortsetzen des Programmes von der aktuellen Stelle aus.
- Bis Cursor: Fortsetzen des Programmes bis zur aktuellen Cursorposition.
- Über Funktion: Ausführen einer Codezeile. Alle in dieser Zeile enthaltenen Funktionen werden ausgeführt.
- Über Maschinenanweisung: Ausführen einer Assemblerinstruktion wie oben.
- In Funktion: Ausführen einer Codezeile. Wenn erforderlich wird aber in die enthaltenen Funktionen verzweigt und diese werden angezeigt.
- In Maschinenanweisung: Ausführen einer Assemblerinstruktion wie oben.
- Aus Funktion: Ausführen bis zum Ende des aktuellen Stackframes (Funktion).
- Ansichten: Erlaubt verschieden Ansichten der Daten. Zur Zeit sind implementiert:
  1. Speicher
  2. Disassemblieren
  3. Register
  4. Bibliotheken
- Anhalten: Ausführung der Anwendung unterbrechen.
- Halt: Ausführung der Anwendung unterbrechen und Debugger beenden.

#### Details

#### Unterbrechungen

Unterbrechungen können auf Quellcodezeilen gesetzt werden (sog. Breakpoints), oder auch auf Variablen (sog. Watchpoints) . Beide Arten von Unterbrechung können jederzeit gesetzt werden, Watchpoints auf lokale Variablen sind jedoch nur im jeweiligen Gültigkeitsbereich von Bedeutung. Sinnvoller ist die Verwendung von Watchpoints für globale Variablen.

#### Setzen/Löschen von Unterbrechungen

Klicken Sie im Editor in der gewünschten Zeile den schmalen "Icon"-Rand auf der linken Seite des Quelltextes an, um eine Unterbrechung zu setzen. Nochmaliges Klicken entfernt die Unterbrechung wieder.

#### Alternative Manipulation der Unterbrechungen via Menü

Wenn Sie den Breakpoint entweder im Editor oder in der Breakpointliste mit der rechten Maustaste anklicken, öffnet sich ein Menü mit Optionen. Dort können Sie die Unterbrechung entfernen oder editieren, oder alle Unterbrechungen löschen.

#### Editieren von Unterbrechungen

Benutzen Sie das eben beschriebene Menü um Unterbrechungen zu editieren. Es enthält die folgenden Einträge:

1. Bedingung: Geben Sie eine Bedingung an, die erfüllt sein muß, damit gdb die Programmausführung unterbricht.
2. Ignoriere die nächsten: Wie oft der Code den Breakpoint passieren soll, bevor gdb die Programmausführung unterbricht.
3. Aktivieren: Wenn das Kontrollfeld aktiviert ist, hält gdb an dieser Stelle an, sonst wird der Breakpoint ignoriert.

#### Alle Breakpoints löschen

Entfernt alle Unterbrechungen für dieses Programm.

#### Setzen/Löschen von Watchpoints

Klicken Sie in der Variablenansicht mit der rechten Maustaste auf eine Variable. Es öffnet sich ein Popup Menü in dem Sie einen Watchpoint auf diese lokale Variable setzen können. Diese Funktionalität ist auf den Gültigkeitsbereich dieser Variablen eingeschränkt. Sobald der Gültigkeitsbereich verlassen werden soll, wird das Programm angehalten und der Watchpoint gelöscht.

WARNUNG: Dies ist als problematisch bekannt. Seien Sie also vorsichtig, wenn Sie Unterbrechungen auf lokale Variablen setzen.

Eine Unterbrechung kann auch gesetzt werden, indem Sie mit der rechten Maustaste auf eine vorher eingegebene Unterbrechung klicken und "Watchpoint umschalten" auswählen.

#### Setzen/Löschen von Watch Variablen

Am unteren Ende der Variablenansicht befindet sich das "Watch"-Feld in dem man den Variablennamen eingeben kann, den man sich in der Watchliste anzeigen lassen will. Geben Sie den Variablennamen gefolgt von <RETURN> ein oder klicken Sie auf "Hinzufügen" . Ein Klick mit der rechten Maustaste auf den Variablennamen in der Baumansicht öffnet ein Menü, in dem Sie die Variable wieder aus der Liste entfernen können.

Sie können eine Watchvariable auch eingeben, indem Sie mit der rechten Maustaste im Editorfenster auf den Variablennamen klicken. Dies öffnet ein Popoup Menü mit einem "Beobachten : Variablenname" Eintrag.

#### Ändern von Variablenwerten

Das ändern von Variablenwerten erfolgt mit Hilfe einer Watchvariablen. Wenn Sie eine Variable "test" haben, können Sie die Variable auf 5 setzen, indem Sie im Watch-Feld "test=5" eingeben und die Variable zur Liste hizufügen. Beachten Sie, daß "test" JEDESMAL auf 5 gesetzt wird, wenn das Programm an dieser Stelle angehalten wird. Sie sollten eine Variable deshalb wieder aus der Liste entfernen nachdem sie einmal gesetzt worden ist.

### 12.3 Die schwebende Werkzeugleiste

Die schwebende Werkzeugleiste ist ein Feature des internen Debuggers, das den Komfort beim Debuggen von GUI Anwendungen erheblich verbessert. Die Werkzeugleiste "schwebt" entweder über allen angezeigten Fenstern, oder sie ist in die Kontrolleiste gedockt. Wenn sie gedockt ist, können Sie den Code durch anklicken des gedockten Icons ausführen. Die dabei ausgeführte Funktion ist die "Step Over" Funktion. Mit Hilfe der rechten Maustaste können sie die Werkzeugleiste wiederherstellen und optional KDevelop den Fokus geben.

Zusätzlich zu den Funktionen des Debugmenüs, bietet die schwebende Werkzeugleiste zwei weitere Funktionen an:

- Setze Fokus auf KDevelop : Setzt den Fokus auf KDevelop.
- Setze Fokus auf Applikation : Setzt den Fokus auf das Fenster das ihn hatte als "Setze Fokus auf KDevelop" gedrückt wurde. Dies ist ein Kompromiß, der Fokus sollte eigentlich auf die zu debuggende Anwendung gesetzt werden, aber dies ist schwierig. Wenn jemand eine bessere Lösung hat, laßt es uns wissen.

Wenn gdb das Programm unterbricht, weil z.B. ein Breakpoint erreicht wurde, wird "Setze Fokus auf KDevelop" mit einem Highlight versehen. Wir geben nicht automatisch KDevelop den Fokus, damit Sie die Ausgabe Ihres Programmes sehen können. Klicken Sie auf "Setze Fokus auf KDevelop" oder einen anderen Knopf um die gewünschte Funktion auszuführen.

### 12.4 Dynamische Bibliotheken und Unterbrechungen

Die Verwendung Breakpoints innerhalb von dynamischen Bibliotheken führt zu einem Problem, für das es eine annehmbare Lösung gibt. Das Problem ist, daß gdb keine Breakpoints akzeptiert, die innerhalb des Quellcodes einer dynamischen Bibliothek liegen, solange diese noch nicht mittels dlopen geöffnet wurde.

Die Lösung besteht darin, gdb dazu zu bringen uns zu benachrichtigen, wenn eine dynamische Bibliothek geöffnet wurde. Das heißt, wenn der Benutzer dort eine Unterbrechung setzt, markieren wir dies als "in der Schwebe", und wenn gdb anhält, weil die Bibliothek geöffnet wurde, versuchen wir die Breakpoints zu setzen. Ist dies erfolgreich, wird die Unterbrechung als aktiv markiert, wenn nicht, bleibt der Breakpoint "schwebend". In jedem Falle wird anschließend ein "continue" ausgeführt.

Dies ist als "lazy breakpoints" bekannt.

Es kann jedoch zu einem Problem kommen, wenn Sie das "Über Funktion" Kommando benutzen und über Code springen, der eine Bibliothek lädt. Es wird eine Unterbrechung beim Laden der Bibliothek ausgelöst, und der Debugger würde normalerweise ein "continue" ausführen (d.h. er würde bis zur nächsten Unterbrechung oder bis zum Ende des Codes ausführen). Der Benutzer erwartet jedoch, daß das Programm in der nächsten Zeile anhält. Deshalb wird in dieser Situation kein "continue" ausgeführt, sondern wir lassen das Programm an diesem Punkt (dies wird irgendwo innerhalb des dlopen Kommandos sein). Das mag etwas verwirren, kann aber nicht vermieden werden.

Weiter Zurück Inhaltsverzeichnis