Dynamische Adaption in heterogenen verteilten eingebetteten ...

4 Basisschicht eines Verwalters
Das Speichern von Debuginformationen ist in Mach-O Dateien nicht vorgesehen. Üblicherweise
werden stabs-Debugstrings in der Symboltabelle abgelegt.
Vergleich und Bewertung der Formate
Die meisten heute gebräuchlichen Binärformate eignen sich, um Module zu definieren. Ältere Formate
wie beispielsweise das a.out sind weniger geeignet, da durch die Einschränkung auf sieben Sektionen
die Struktur der Software nicht immer ausreichend beschrieben werden kann.
Das COFF-Format, in der ursprünglichen Fassung, ist ebenfalls weniger geeignet. Die Längenbeschränkung
der Sektionsnamen auf acht Zeichen erschwert eine nachvollziehbare Aufteilung der
Struktur unnötig. Die in COFF zusätzlich integrierten Debuginformationen sind für unser Ziel ebenfalls
nicht ausreichend, da sich die Typinformationen auf einfache Standardtypen beschränken.
Besser geeignet sind die Erweiterungen des COFF-Formats. Hier ist im Speziellen Microsofts PE-
COFF zu nennen. Durch die weite Verbreitung von Windows ist auch dieses Format gut unterstützt und
auch im Bereich der eingebetteten Systeme verbreitet. Die extern gespeicherten Debuginformationen
enthalten umfangreiche Typinformationen, jedoch ist das Format nicht offiziell beschrieben. Die angebotene
Bibliothek zum Einlesen und Verarbeiten der Informationen ist nur für Windows-Betriebssysteme
verfügbar.
Daher werden wir im Weiteren dieser Arbeit das ELF-Format einsetzen. Es bietet ebenfalls die
Möglichkeit, beliebig viele Sektionen zu definieren und damit die Struktur der Software auszudrücken.
Die Erstellung und Verarbeitung wird durch die frei verfügbare Binary Format Description Bibliothek
(BFD) unterstützt. Auf dieser Bibliothek basieren viele andere Softwarewerkzeuge wie beispielsweise
die GNU Compiler Collection (GCC). Die GCC ist weit verbreitet und bietet verschiedene Compiler
für eine Vielzahl von Architekturen an. Zudem ist die einfache und automatische Integration von
standardisierten und umfangreichen Debuginformationen (im DWARF-Format) möglich.
Mach-O wäre prinzipiell auch geeignet, da auch hier Möglichkeiten bestehen, die Struktur der Software
feingranular darzustellen. Besonders interessant ist hier außerdem die Möglichkeit, binären Code
für verschiedene Architekturen in einer einzigen Datei abzulegen. Das Mach-O Format wird jedoch
kaum bei der Entwicklung von eingebetteten Systemen eingesetzt, daher ist die Werkzeugunterstützung
auf wenige Architekturen beschränkt.
4.2.5 Erstellung der Module
Nachdem der grundsätzliche Aufbau und verschiedene Formate von Binärdateien betrachtet wurden,
soll nun gezeigt werden, wie man daraus Module definieren kann. Als Ausgangsbasis werden
Objektdateien im ELF-Format zugrunde gelegt.
Grober Aufbau einer ELF-Datei
Zunächst soll der Aufbau einer ELF-Objektdatei im Detail betrachtet werden. Abbildung 4.4 zeigt den
Aufbau schematisch. Alle enthaltenen Daten werden in einzelnen ELF-Sektionen gespeichert. Eine
Tabelle gibt Aufschluss über die Position und den Typ der einzelnen ELF-Sektionen. Der Compiler legt
normalerweise mindestens zwei oder drei Sektionen mit binären Daten an. Eine für den Code, eine für
die Daten und eine, welche den Platzbedarf der nicht initialisierten Daten beschreibt (.bss-Sektion).
Zu jeder Sektion kann eine Relokationstabelle gespeichert sein, die auf Positionen innerhalb dieser
Sektion wirkt. Relokationstabellen werden jeweils in eigenen ELF-Sektionen gespeichert. Daneben
gibt es noch mindestens eine ELF-Sektion, die eine Symboltabelle enthält. Diese beschreibt die
48