Linux-Magazin Clean Linux (Vorschau)

Know-how
www.linux-magazin.de Embedded Debugging 09/2013
86
Abbildung 1: Remote Debugging lässt sich über die Kommandozeile oder ein IDE wie Eclipse bewerkstelligen.
informieren. Die Technik heißt, in Anlehnung
an den Funktionsaufruf in C, meist
einfach nur Printf. Sie hat den Nachteil,
dass der Entwickler das Programm anpassen
und die zu beobachtenden Teile
vor dem Übersetzen kennen muss. Dafür
steht der schlichte Ansatz fast immer zur
Verfügung.
Die Ausgabe muss nicht über einen Bildschirm
laufen, für den die Zielsysteme oft
keine Schnittstelle mitbringen, sondern
kann über einen Ethernet-Port oder eine
serielle RS232-Verbindung erfolgen. Fehlt
auch diese, etwa bei sehr einfachen Systemen,
lässt sich eine LED einsetzen, die
ein Muster blinkt, das den Programmfortschritt
anzeigt.
Gemeinsam ist diesen Ansätzen, dass sie
keine explizite Kopplung des Zielsystems
mit dem Entwicklungssystem voraussetzen,
sondern dass der Entwickler seine
Schlüsse aus den Ausgaben des Zielsystems
zieht, die er dann auf dem Entwicklungssystem
umsetzt.
Remote Debugging
Eine komfortablere Fehlersuche schließt
einen Debugger wie GDB [1] ein. Mit
dessen Hilfe unterbricht der Entwickler
die Ausführung seines Programms an bestimmten
Stellen, verfolgt sie Quelltextzeile
für Quelltextzeile weiter, kontrolliert
und manipuliert den Inhalt von Registern
und Variablen.
In der klassischen Software-Entwicklung
finden sowohl die Analyse als auch die
Ausführung des Programms auf dem Entwicklungssystem
statt, das dem Zielsys-
tem sehr stark ähnelt. Eine Entwicklungsumgebung
(Abbildung 1) unterstützt den
Programmierer und erleichtert die Analyse.
Dies setzt voraus, dass die untersuchte
Software auf demselben Rechner
läuft wie der Debugger beziehungsweise
die Entwicklungsumgebung.
Weil dies bei eingebetteten Systemen oft
nicht zutrifft, kommt Remote Debugging
zum Einsatz. Dabei startet der Entwickler
auf dem Zielsystem eine Helfer-Applikation,
mit der sich der Debugger des
Entwicklungssystems verbindet, zum
Beispiel über Ethernet oder die serielle
RS232-Schnittstelle.
Im Falle von GDB führt der Zielrechner
einen GDB-Server aus, bei dem sich der
GDB-Client auf dem Entwicklungssystem
anmeldet. Der Client leitet nun Anweisungen
an die Serverinstanz auf dem
Zielsystem weiter, um zum Beispiel das
untersuchte Programm anzuhalten oder
die Registerinhalte auszulesen. Zugleich
steuert der Programmierer die Anwendung
auf diesem Weg.
Der Server setzt die Anweisungen um
und schickt die Resultate an das Entwicklungssystem
zurück. Dessen Debugger
Cross-Toolchain
Bei der Entwicklung für eingebettete Systeme,
die zum Beispiel ARM-Prozessoren verwenden,
kann der Entwickler die systemeigene Compiler-Toolchain
(Assembler, Compiler, Linker
und Debugger) des Entwicklungssystems nicht
verwenden, um Quelltext in Binärcode für das
Zielsystem zu übersetzen.
Hier kommt eine Cross-Toolchain zum Einsatz,
die auf dem Entwicklungssystem läuft, während
übernimmt dann die rechenintensiven
Aufgaben. Er gleicht Assembler-Instruktionen
mit bestimmten Quelltextzeilen ab
und ordnet Variablen richtig zu.
Debugging über Kreuz
Unterscheiden sich die Architekturen von
Entwicklungs- und Zielsystem, versteht
der Debugger des Entwicklungssystems
weder die Assembler-Instruktionen des
Gegenübers, noch kennt er dessen Register.
Das verhindert ein direktes Auswerten
von Variablen und Zuordnen von
Instruktionen zum Quelltext.
Dieses Problem löst ein so genannter
Cross-Debugger, der Bestandteil der
Cross-Toolchain ist. Er lässt sich ebenfalls
auf dem Entwicklungssystem ausführen,
versteht jedoch die Assembler-Instruktionen
des jeweiligen Zielsystems. Das
macht es unter anderem möglich, mit
Hilfe von Remote Debugging ein ARM-
Programm auf einem x86-System zu untersuchen
(Abbildung 2).
Im Falle von Android stellt Google beispielsweise
Entwicklungsumgebungen
für Smartphone- und Tablet-Entwickler
bereit. Letztere können beim Remote Debugging
kaum noch unterscheiden, ob
die Anwendung auf dem Endgerät oder
dem Rechner des Entwicklers läuft. Auf
dem Entwicklungssystem arbeitet dabei
ein Emulator.
DIY: Remote Debugging
Die eben vorgestellte Form des Remote
Debugging setzt voraus, dass das Zielsystem
mehrere Programme zugleich
ausführen kann, also mindestens das
zu untersuchende Programm und ein
Hilfsprogramm wie den GDB-Server. Das
funktioniert zum Beispiel problemlos,
wenn auf dem Zielsystem ein Betriebssystem
wie etwa Linux läuft.
der von ihr erzeugte Binärcode nur auf dem
Zielsystem funktioniert. Gleiches gilt für den
Debugger in der Cross-Toolchain, der nur den
Binärcode des Zielsystems versteht.
Cross-Toolchains auf GCC-Basis lassen sich bei
den meisten Linux-Distributionen für verschiedene
Zielarchitekturen aus der Paketverwaltung
heraus installieren oder durch entsprechende
Skripte einfach selbst übersetzen.