Vereinte Welten

Java-Anwendungen zu debuggen ist eine bekannte Disziplin. Seit Mitte 2006 unterstützt Lauterbach die Fehlersuche in den Java Virtual Machines J2ME CLDC, J2ME CDC und Kaffe. Da längst sind nicht mehr alle virtuellen Maschinen nach dem Open-Source-Modell vorliegen, wird die Fehlersuche aber immer schwieriger. Um VM-Anbietern und ihren Kunden die Möglichkeit zu geben, das Debugging schnell und flexibel für ihre VM anzupassen, arbeitet Lauterbach seit Mitte 2010 an einer offenen Lösung. Als Referenz für die Entwicklung einer VM-API für Stop-Mode-Debugging kommt die für ARM-Cores implementierte Android-VM namens Dalvik zum Einsatz.

Zwei Debug-Welten

Aus Entwicklersicht ist Android ein Open-Source-Stack mit drei Hauptkomponenten: Erstens ein Linux-Kernel mit seinen Hardware-Treibern, zweitens die Android-Runtime mit der Dalvik Virtual Machine und einer Reihe von Bibliotheken, sowie drittens die in Java programmierten Anwendungen und das sie unterstützende Application Framework. Der Linux-Kernel, einige Libraries und die Dalvik Virtual Machine selbst sind in C, C++ oder Assembler implementiert. Die VM-Anwendungen und das sie unterstützende Application Framework werden in Java programmiert. Getestet wird der jeweilige Code in seiner eigenen Debug-Welt.

Den in C, C++ und Assembler geschriebene Android-Teil kann man hardwarenah via Jtag-Schnittstelle im Stop-Mode debuggen. Lauterbachs Trace32 kommuniziert dazu direkt mit dem Prozessor der Android Hardware-Plattform (Bild 1). Charakteristisch für Stop-Mode-Debugging ist, dass das gesamte Android-System stoppt, sobald der Prozessor für das Debugging angehalten wird. Debugger und Prozessor brauchen hierfür nur eine Jtag-Kommunikation, aber keinen Debug-Server auf dem Target. Damit eignet sich Stop-Mode-Debugging auch für das Testen von Release-Software sowie unter realen Zeitbedingungen – wichtig für Probleme, die erst unter Echtzeitbedingungen auftreten. Stop-Mode-Debugging unterstützt derzeit jedoch keine VM-Anwendungen, zum Beispiel in Dalvik. Daher ist ein transparentes Debugging durch alle Software-Schichten bisher nicht möglich.

Bild 1: Beim Stop-Mode Debugging kommuniziert der Debugger direkt mit dem Prozessor auf der Android Hardware-Plattform.Lauterbach

Java-Code für Android wird üblicherweise mit den in Eclipse integrierten Android Development Tools (ADT) getestet. Der ADB-Server (Android Debug Bridge) auf dem Host kommuniziert dazu via USB oder Ethernet mit dem ADB-Daemon auf dem Target (Bild 2). Voraussetzung für das Testen mit ADT sind speziell für Debugging kompilierte VM-Anwendungen und eine Deklaration der Debug-Erlaubnis im Application Manifest. Zudem muss Debugging für die Hardware-Plattform freigeschaltet sein.

Bild 2: Die in Eclipse integrierten Android Development Tools (ADT) zum Debuggen von Java-Code.Lauterbach

Java-Debugging mit ADT und Eclipse ist zwar recht komfortabel, hat aber klare Grenzen: Es erkennt keine Fehler, die erst mit dem Release-Code auftreten, sowie Fehler, die erst dann auftreten, wenn die Java-Anwendung mit einem in C oder C++ angebotenen Dienst oder einem Linux-Hardware-Treiber interagiert. Außerdem geht nichts ohne die Kommunikation zwischen ADB-Server und ADB-Daemon.

VM Aware Stop-Mode Debugging

Um durchgängiges Testen eines Android-Systems von der Java-Anwendung bis hinunter zum Linux-Hardware-Treiber unter Real­zeit­bedingungen zu ermöglichen, erweitert Lauterbach das Stop-Mode-Debugging um eine so genannte VM Debugging Awareness. Der Jtag-Debugger kommuniziert dabei direkt mit dem Prozessor auf der Android Hardware-Plattform. Folglich kann er nach dem Anhalten des Prozessors auf alle Systeminformationen zugreifen. Die Herausforderung für den Debugger besteht nun darin, die richtigen Informationen zu finden und für den Nutzer leicht verständlich, von Bits und Bytes abstrahiert, darzustellen.

Durch eine Abstraktionsebene können Trace32-Nutzer bereits Betriebssystemsoftware über mehrere virtuelle Adressräume hinweg debuggen. Java-Debugging ist nun eine weitere, bisher vom Betriebssystem-Debugging unabhängige Abstraktionsebene. Um die in Systemen wie Android auf VMs laufende Anwendungen zu analysieren, muss man Betriebssystem- und Java-Debugging kombinieren. Das Stop-Mode-Debugging unterstützt daher künftig folgende Abstraktionsebenen:

• Hochsprachen-Debugging
• Target-OS Debugging Awareness
• VM Debugging Awareness

Hochsprachen-Debugging ist fester Bestandteil der Trace32-Software und wird mit dem Laden der Symbol- und Debug-Informationen für ein Programm passend konfiguriert. Die Target-OS Debugging Awareness muss vom Nutzer konfiguriert werden; für alle gängigen Betriebssysteme gibt es fertige Konfigurationen. Die VM Debugging Awareness ist für J2ME CLDC, J2ME CDC und Kaffe Bestandteil der Trace32-Software. Alle anderen virtuellen Maschinen können mit der VM-API individuell angepasst werden. Für die populäre Android Dalvik-VM steht, ähnlich wie für die Target-OS Debugging Awareness, eine fertige Konfiguration zur Verfügung. Diese offene Lösung erlaubt es auch Anbietern von Closed-Source-VMs, eine Trace32-VM-Awareness für ihr Produkt zu erstellen und ihren Kunden anzubieten.

Referenzimplementierung

Derzeit ist es auf einem ARM-basierten Android-Target möglich, alle Java-Anwendungen, die gerade ausgeführt werden, zu ermitteln und aufzulisten („EXTension.VMList“ im Bild 3). Ebenso lässt sich der VM-Stack für eine ausgewählte Java-Anwendung analysieren und darstellen („EXTension.VMView“ im Bild 3). Als nächster Schritt ist geplant, den von der VM gerade ausgeführten Quellcode anzuzeigen. Das Ziel der Entwicklung lautet: Stop-Mode-Debugging für VM-Anwendungen mit allen Funktionen eines modernen Debuggers, mit dem künftig der Embedded-Entwickler den kompletten Code-Stapel von den Java-Quellen bis hinab zum Hardware-Treiber im Linux-Kernel debuggen kann.

Bild 3: Für die Referenzimplementierung muss die Linux OS-Awareness und die Dalvik VM-Awareness in Trace32 geladen werden.Lauterbach

(lei)