Dynamische Adaption in heterogenen verteilten eingebetteten ...

4 Basisschicht eines Verwalters
Architektur .text .rodata .data .bss Total
Atmel AVR ATmega 566 0 20 0 586 Byte
Renesas H8/300 248 20 0 0 268 Byte
Intel x86 316 20 0 0 336 Byte
Tabelle 4.6: Größe eines minimalen Fernwartungsmoduls (RCM) in Byte
In dieser Tabelle ist die Größe eines minimalen Fernwartungsmoduls dargestellt. Auch hier ist die Version für AVR-
Mikrocontroller deutlich größer, da zusätzliche Funktionen zum Beschreiben des Flashspeichers notwendig sind. Das
Zwischenspeichern einer Flashseite wird in dieser Implementierung auf dem Stack durchgeführt, sodass der Speicher
hierfür nicht in dieser Tabelle auftaucht.
Im Rahmen einer Studienarbeit [Oec07] wurde außerdem ein RCM für das Betriebssystem TinyOS
entwickelt. Dieses ist vom Funktionsumfang mit dem komfortablen Fernwartungsmodul aus der ersten
Tabelle vergleichbar. Es wurden jedoch keine Optimierungen zur Größenreduktion durchgeführt und
kann somit nicht direkt verglichen werden. Es belegt 2789 Byte Speicher.
4.5.8 Schnittstellenbeschreibung und Typinformationen
Zur Durchführung von Fernaufrufen und zum Anpassen von Datenstrukturen beim Aktualisieren
und Ersetzen von Modulen müssen Typinformationen vorliegen, um binären Daten eine Struktur
zuzuordnen. Diese Informationen können zum großen Teil aus Debuginformationen gewonnen werden
(siehe Abschnitt 4.2.6). In der vorliegenden Arbeit werden DWARF-Debuginformationen ausgewertet,
da dieses Format das Standarddebugformat für ELF-Objektdateien darstellt.
4.5.8.1 Verarbeiten von DWARF-Debuginformationen
Das Auswerten der DWARF-Debuginformationen aus den ELF-Dateien wird durch ein Objekt vom
Typ DwarfLoader übernommen. Beim Einlesen der Objektdatei werden unbekannte Sektionen an
dieses Objekt übergeben, welches prüft, ob es sich um Debuginformationen handelt. Für das Auswerten
der DWARF-Informationen wird zunächst die Sektion mit dem Namen .debug_abbrevbenötigt.
Sie enthält Informationen über den genauen Aufbau der Sektion .debug_info. Dort wiederum
sind die Informationen zu den einzelnen Programmelementen abgespeichert. Der genaue Aufbau der
DWARF-Informationen ist für die weitere Arbeit nicht relevant, daher wird an dieser Stelle nicht weiter
darauf eingegangen.
Das DwarfLoader-Objekt wird mit dem ELFFile-Objekt verknüpft, da sich die Debuginformationen
auf den Inhalt einer Objektdatei beziehen. So stehen die Informationen bei der Modulerzeugung
zur Verfügung. Der ELFSectionExtractor, der Module aus einer Objektdatei
erzeugt, greift auf das DwarfLoader-Objekt zurück, um jedem erzeugten Modul Typinformationen
zuzuordnen. Für jedes Funktionsmodul wird ein Objekt von Typ Subprogramm erstellt, welches
die Schnittstellenbeschreibung der Funktion in einem DWARF-unabhängigen Format speichert. Für
Datenmodule wird ein Objekt vom Typ DataType erstellt und zugeordnet (siehe Abbildung 4.22).
Im Rahmen dieser Zuordnung werden auch zusätzliche Debuginformationen ausgewertet. Besonders
hilfreich ist beispielsweise die Information, ob eine Funktion in eine andere Funktion integriert wurde
(inlined). In diesem Fall wird eine spezielle Abhängigkeit vermerkt, da die integrierte Funktion nicht
ohne Weiteres ausgetauscht werden kann, ohne die umgebende Funktion neu zu erstellen.
Die Schnittstellenbeschreibung in Form des Subprogramm-Objekts liefert den Datentyp des
Rückgabewerts und eine Liste mit Informationen über die Parameter als Feld von DataComponent-
Objekten. Diese Objekte enthalten wiederum den Namen, den Datentyp und eine Ortsangabe zu einem
88