Dynamische Adaption in heterogenen verteilten eingebetteten ...

4 Basisschicht eines Verwalters
Zeit von vielen UNIX-Systemen eingesetzt, so zum Beispiel auch von Linux bis zur Kernel Version 1.2.
Inzwischen hat es jedoch kaum noch Bedeutung, da es fast überall durch Nachfolgeformate wie COFF
oder ELF abgelöst wurde.
Im Laufe der Zeit existierten verschiedene Versionen des Formats. Im ursprünglichen Format
(OMAGIC) wurde nicht zwischen initialisierten Daten und Programmcode unterschieden, das wurde
erst in neueren Versionen (NMAGIC) eingeführt, um Programmcode schreibgeschützt zu laden. In
einer weiteren Version (ZMAGIC) wurden dann Speicherseiten unterstützt, sodass einzelne Seiten erst
bei Bedarf in den Prozess eingeladen werden konnten.
Das a.out-Objektformat ist, je nach Version, in bis zu sieben Abschnitte unterteilt. Darunter befindet
sich neben einem Codeabschnitt (text segment) und einem Datenbereich (data segment) auch Relokationsinformationen
(getrennt nach text relocations und data relocations) und eine Symboltabelle
(symbol table). Symbolnamen sind im ursprünglichen a.out-Format auf eine Länge von acht Zeichen
beschränkt. Durch die Einführung einer Stringtabelle können sie jedoch in neueren Versionen auch
länger sein.
Eine Speicherung von Debuginformationen ist im a.out-Objektformat nicht vorgesehen. Es gibt
jedoch die Möglichkeit Debuginformationen im stabs-Debugformat (siehe Abschnitt 4.2.6.1) als
Symbole einzufügen.
COFF
Das Common Object File Format (COFF) [Gir88, Del96] ist der Nachfolger des a.out-Formats. Es
wurde mit UNIX System V Release 3 (SVR3) eingeführt, um einige Schwächen von a.out auszubessern.
So ist es in COFF möglich, mehrere Sektionen unterschiedlicher Typen zu definieren. Hierzu wurde im
Dateikopf eine Tabelle der Sektionen eingeführt, die zu jeder Sektion auch einen Namen führt. Der
Name einer Sektion ist jedoch auf höchstens acht Zeichen beschränkt. Sektionen kann der Typ Code
(.text), initialisierte Daten (.data) oder nicht initialisierte Daten (.bss) zugeordnet werden.
Außerdem wurde ein einfaches Format definiert, um grundlegende Debuginformationen in einer
COFF-Datei speichern zu können (siehe Abschnitt 4.2.6.1). Das Format der Debuginformationen ist
jedoch für die Sprache C optimiert und bietet keine Erweiterungsmöglichkeiten, sodass man damit
schnell an Grenzen stößt.
XCOFF Um diese Einschränkungen und die mangelnden Erweiterungsmöglichkeiten zu umgehen,
hat IBM das COFF-Format für ihr UNIX-Derivat AIX erweitert. Es entstand XCOFF (eXtended COFF),
welches später auch in einer 64-bit-Version definiert wurde [Ibm04]. In XCOFF wurden zusätzliche
Sektionstypen eingeführt, um beispielsweise das dynamische Binden zu vereinfachen. Außerdem
kann eine Sektion mit Typinformationen angelegt werden, um eine grundlegende Typprüfung beim
Binden von mehreren Dateien durchzuführen. Die Behandlung von Ausnahmen (traps, exceptions)
wird durch eine Sektion unterstützt, welche die Quelle und den Grund von potenziell auftretenden
Ausnahmen enthält. Allgemeine Debuginformationen werden in einer eigenen Sektion im erweiterbaren
stabs-Format abgelegt.
eCOFF Neben XCOFF gibt es noch eine andere Erweiterung namens eCOFF (extended COFF)
[Com99] für Alpha und MIPS-Architekturen. eCOFF bietet vor allem verbesserte Unterstützung für
dynamisches Binden. Außerdem können die Binärdaten in eCOFF komprimiert abgelegt werden, um
Speicherplatz zu sparen.
46