Linux-Magazin Clean Linux (Vorschau)

Manchmal untersucht der Entwickler
jedoch Programme, die ohne Betriebssystem
funktionieren, oder er will Fehler
im Betriebssystem selbst aufspüren. Die
Programme im ersten Fall heißen Bare-
Metal-Applikationen, da sie ohne Zwischenschicht
direkt auf der Hardware
laufen. Auch sie lassen sich mit einem
gewissen Mehraufwand über Remote-
Debugging-Techniken erforschen.
Eine Variante besteht darin, spezielle Debug-Routinen
in das zu untersuchende
Programm einzuschleusen. So kann
dieses selbst als Debug-Server arbeiten,
mit dem sich der Debugger des Entwicklungssystems
dann verbindet. Was GDB
betrifft, stehen für einige Architekturen
(mit Ausnahme von beispielsweise ARM)
fertige Bibliotheken bereit, die nur ein
geringfügiges Eingreifen des Programmierers
erfordern. Sobald die Routinen
in dem zu untersuchenden Programm
stecken, kann sich der Debugger auf der
Entwicklungsmaschine über eine serielle
RS232-Verbindung mit dem Zielsystem
verbinden.
Diese Variante des Remote Debugging
lässt sich auch für den Linux-Kernel einsetzen,
der unter der Bezeichnung KGDB
bereits Routinen mitbringt, die ihn in einen
GDB-Server verwandeln. Aktiviert
man die passenden KGDB-Optionen (zum
Beispiel »CONFIG_KGDB=y« und »CON-
FIG_KGDB_SERIAL_CONSOLE=y«), lässt
er sich über eine serielle Verbindung wie
jedes andere Bare-Metal-Programm untersuchen.
Debugging via JTAG
Sollte auch die Erweiterung des zu untersuchenden
Programms nicht möglich
oder zu aufwändig sein, lässt sich die
Software im Embedded-Bereich auch mit
Hilfe spezieller Debugging-Schnittstellen
der Hardware genauer untersuchen. Als
JTAG
JTAG steht als Kürzel für Joint Test Action
Group und ist die geläufige Bezeichnung für den
IEEE-Standard 1149.1. Dieser implementierte ursprünglich
lediglich einen Boundary-Scan-Test,
mit dem es möglich ist, Zustände von Flipflops
in einer kompletten Schaltung auszulesen. Obwohl
der Standard in der Zwischenzeit wesentlich
erweitert wurde, bleibt der Boundary-Scan-
Test der wichtigste Bestand teil und der Begriff
Abbildung 2: Um ARM-Programme auf einem
herkömmlichen x86-System zu debuggen, hilft der
Einsatz eines Cross-Debuggers.
Standard hierfür hat sich inzwischen die
JTAG-Schnittstelle etabliert (siehe Kasten
„JTAG“).
Diese ermöglicht es, den Prozessor des
Zielsystems an den zur Laufzeit genutzten
Steuerungsmöglichkeiten vorbei zu
dirigieren. Der Entwickler kann ihn anhalten,
die instruktionsweise Ausführung
eines Programms erzwingen, aber
auch die Register- und Speicherinhalte
auslesen und manipulieren. Die JTAG-
Kette akzeptiert sogar mehrere Geräte,
wodurch sich auch Koprozessoren, zum
Beispiel digitale Signalprozessoren, ansteuern
lassen.
Wer auf die JTAG-Schnittstelle zugreifen
möchte, benötigt einen Adapter, den
es für die ARM-Plattformen bereits ab
zirka 25 Euro gibt und den man per USB-
wird von manchen Entwicklern als Synonym für
JTAG verwendet.
Neben dem Auslesen von Flipflops lassen sich
mit JTAG inzwischen auch eingebettete Schaltungen
wie Microcontroller, System-on-Chips
und Field Programmable Gate Arrays (FPGA)
steuern und überwachen. Er basiert auf einem
seriellen Protokoll, welches das entsprechende
Gerät über einen Zustandsautomaten steuert.
oder RS232-Schnittstelle mit dem Entwicklungsrechner
verbindet. Die Nutzer
der Schnittstelle gehen dann nach dem
Schema des Remote-Debugging (Abbildung
3) vor. Dabei stellt der JTAG-Debug-Server
eine Brücke zwischen JTAG-
Schnittstelle und Debugger auf dem Entwicklungssystem
her.
Für den Debugger erscheint die JTAG-
Schnittstelle nun wie ein Remote-Server.
Letzterer übersetzt die Kommandos des
Debuggers (beispielsweise zum Anhalten
der Software oder zum Auslesen von
Registern) in den entsprechenden JTAG-
Befehlsstrom und wandelt die über JTAG
ausgelesenen Werte in ein für den Debugger
verständliches Format. Das erfordert
keine Anpassungen an dem zu untersuchenden
Programm, da die Eingriffe nur
Hardware-seitig stattfinden.
JTAG erweist sich also als sehr bequeme
Möglichkeit zum nicht-invasiven Debugging,
wenn das Zielsystem die entsprechende
Schnittstelle mitbringt. Das ist
jedoch nur bei speziellen Entwicklungsboards
der Fall, während den davon abgeleiteten
Endprodukte diese Schnittstelle
in der Regel aus Kostengründen fehlt. Bei
anderen Geräten sind sie auf der Leiterplatte
vorgesehen, aber nicht bestückt,
sodass sich für Bastler und Hacker interessante
Möglichkeiten [2] ergeben.
Fehlersuche per Emulation
Eine weitere einfache Möglichkeit, um
Fehler in Programmen von eingebetteten
Systemen aufzuspüren, besteht im
Emulieren der Zielplattform. Die Granularität
kann dabei höchst unterschiedlich
sein und reicht von der Emulation
eines API über die Systememulation bis
hin zur vollständigen Simulation. Ein
Anwendungsbeispiel wäre die erwähnte
Entwicklungsumgebung von Google für
Android.
Eine universellere Form der Fehlersuche
per Remote Debugging erlaubt die freie
virtuelle Maschine Qemu. Sie emuliert
komplette Systeme, führt also auch Bare-
Metal-Programme ohne spezielle Anpassung
aus. Sie stellt jedoch zusätzlich eine
GDB-Server-Schnittstelle bereit, die eine
ähnlich umfangreiche Steuerung erlaubt
wie eine JTAG-Schnittstelle und dabei
hilft, die Programmausführung zu manipulieren
und zu untersuchen. Analog zu
Embedded Debugging 09/2013
Know-how
www.linux-magazin.de
87