LLDB ermöglicht Debuggen in Echtzeit Debugging und Troubleshooting in Xcode
Für das Finden von Fehlern oder zum Debuggen von Code in Xcode setzen viele Entwickler auf LLDB. Die Komponente steht direkt in Apples Entwicklungsumgebung zur Verfügung und lässt sich auch in der Shell starten.

LLDB ist die Debugger-Komponente im LLVM-Projekt (Low Level Virtual Machine). Der Debugger kommt auch bei der Programmierung mit Xcode zum Einsatz. Zur Verwendung kommt LLDB entweder über die Oberfläche in Xcode oder durch das Aufrufen in der Shell mit „lldb <Programm>“.
Der Umgang ist nicht so bequem wie bei Debuggern, die direkt in der grafischen Oberfläche starten. Dafür ist die einfache Verwendung aber ein Vorteil, um schnell Probleme zu identifizieren. Die Geschwindigkeit und der sehr geringe Aufwand beim Debuggen sind die beiden größten Vorteile bei der Verwendung von Xcode und Swift mit LLDB.
LLDB ist enorm flexibel
Vor allem um iOS- und iPadOS-Programme während der Laufzeit zu debuggen, kann LLDB eine wertvolle und leicht zu bedienende Hilfe sein. Bereits seit Jahren, fast schon Jahrzehnten, kann LLDB mit Xcode zum Einsatz kommen, um Apple-Programme zu debuggen. Natürlich kann der Debugger auch für tvOS, watchOS und macOS zum Einsatz kommen. Apple stellt LLDB in Xcode im Video „Advanced Debugging with Xcode and LLDB“ ausführlicher vor.
Auch Swift lässt sich mit LLDB nutzen. Apple zeigt die Möglichkeiten im Video „Debug Swift debugging with LLDB“. Mit Objective-C kann LLDB ebenfalls zum Einsatz kommen. Er unterstützt problemlos verschiedene Architekturen, zum Beispiel x86/x64, i386, ARM und AArch64. Es ist auch möglich, LLDB in Python einzubinden. Dazu kommt das Modul „lldb“ zum Einsatz, das sich in Python importieren lässt.
LLDB und Breakpoints für iOS-Apps nutzen
Innerhalb von Xcode kann über Breakpoints definiert werden, wie LLDP läuft. Mit den Breakpoints ist es möglich zu steuern, ob ein Ton oder ein Eintrag in einem Protokoll stattfinden soll. Gleichzeitig lässt sich über Xcode auch definieren, dass ein Breakpoint nur unter bestimmten Bedingungen aktiv ist.
Das kann der Inhalt einer Variablen sein oder auch eine bestimmte Anzahl an Durchläufen, um zum Beispiel Dauerschleifen zu verhindern. Die Breakpoints sind ein ideales Mittel dafür, um den Debugger zu veranlassen an bestimmten Stellen des Programmes einzugreifen, indem der Haltepunkt den Stop auslöst und LLDB den Code nach Fehlern untersucht.
Speicher mit LLDB für das Debuggen auslesen
Sobald die App durch den Breakpoint pausiert, lassen sich zum Beispiel die gesetzten Variablen durchsuchen. Dazu kommen zum Beispiel die Befehle „v“, „p“ oder auch „po“ zum Einsatz. Bei den Befehlen handelt es sich um Aliase.
Mit „v“ kann der Befehl „frame variable“ als Alias genutzt werden, der eine Zusammenfassung der Variablen anzeigt. LLDB zeigt daher an, was sich im Speicher für die Variable befindet. Bei der Ausführung von „v“ wertet LLDB keine Ausdrücke aus und führt auch keine Funktionsaufrufe auf. Berechnete Variablen stehen ebenfalls nicht im Fokus, es geht vor allem um den Speicher.
Generell kann es in Verbindung mit LLDB auch sinnvoll sein, bei Breakpoints das Programm nach einiger Zeit fortzuführen, um Code live für das Debugging zu injizieren. Dadurch muss wegen des Debuggings der Code nicht jedes Mal komplett neu bearbeitet und neu kompiliert werden. Das beschleunigt das Debuggen deutlich und vereinfacht die Vorgänge. Abhängige Breakpoints lassen sich um Beispiel mit „breakpoint set --one-shot true“ in Xcode erstellen. Der Haltepunkt wird gelöscht, sobald er einmal getroffen wurde.
Parallel dazu ist es in LLDB mit dem Befehl „process status“ möglich, den laufenden Status des Debuggings anzuzeigen, inklusive des aktuellen Threads und des Frames im Call Stack. Das ist bei der Verwendung von Python-Skripten unter Umständen nützlich. Gleichzeitig kann „thread backtrace“ in LLDB eine Liste der Frames des aktuellen Threads anzeigen, zum Beispiel mit „thread backtrace all“.
Sollen die Aufrufstapel gruppiert dargestellt werden kommt „thread backtrace unique“ zum Einsatz. Es ist auch möglich zwischen den Threads zu navigieren. Dazu dient der Aufruf „thread select <Nummer>“. Eine Liste aller Threads zeigt LLDB mit „thread list“ an.
Ausdrücke auswerten und Variablen für das Debugging berechnen
Bei „p“ handelt es sich um den Alias des Befehls „expression“. Der Befehl kompiliert den Code, um Ausdrücke auszuwerten. Er kann daher auch Funktionsaufrufe durchführen und Variablen berechnen. Daher werden „v“ und „p“ oft gemeinsam verwendet. Mit „po“ kommt „--object-description“ zum Einsatz. Auch dieser Befehl wertet Ausdrücke aus.
Allerdings gibt „po“ die Debugging-Beschreibung zurück. Dabei handelt es sich um die textbasierte Darstellung einer Instanz des entsprechenden Typs. Hier lassen sich Standardbeschreibungen nutzen oder auch eigene Beschreibungen hinterlegen, gemäß CustomDebugStringConvertible.
Bei der Verwendung von „p“ und „po“ muss darauf geachtet werden, dass diese beiden Befehle den Code dynamisch kompilieren. Die Ausführung dauert natürlich entsprechend länger. Sollen sehr schnell Ergebnisse des Debuggers angezeigt werden, ist „v“ die richtige Wahl. Allerdings muss hier natürlich darauf geachtet werden, dass keine Expressions ausgewertet oder Variablen berechnet werden können. Das schränkt den Nutzen von „v“ ein.
Sollen aber keine Variablen berechnet werden und sind auch keine Expressions vorhanden, dann ist es auch nicht notwendig mit „p“ oder „po“ Ressourcen und Zeit zu verschwenden. Sinnvoll kann an dieser Stelle auch die Verwendung sogenannter Watchpoints sein. Sobald sich der Wert einer Variable das nächste Mal ändert, unterbricht ein Watchpoint den Debugger und arbeitet daher generell wie ein Breakpoint.
Fazit
Bei der Entwicklung mit Xcode, Swift und auch Python macht es durchaus Sinn sich die Möglichkeiten von LLDB anzuschauen, um Programme sehr viel schneller zu debuggen, als mit vielen anderen Tools. Auch in der Shell kann der Debugger durchaus einiges an Möglichkeiten bieten, die zwar teilweise etwas kompliziert sein kann, dafür aber sehr schnell in der Ausführung ist.
(ID:48861054)