Benutzerhandbuch zu KDevelop: Der Referenzführer zur KDevelop Integrierten Entwicklungsumgebung für Unix Systeme, Version 1.2 | ||
---|---|---|
Zurück | Kapitel 12. Der interne Debugger | Vor |
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.