Um zu verstehen, warum FreeBSD das Format elf(5) benutzt, müssen Sie zunächst etwas über die drei gegenwärtig „dominanten“ ausführbaren Formate für UNIX® Systeme wissen:
Das älteste und „klassische“ Objektformat von UNIX® Systemen. Es benutzt einen kurzen, kompakten Header mit einer magischen Nummer am Anfang, die oft benutzt wird, um das Format zu charakterisieren (weitere Details finden Sie unter a.out(5)). Es enthält drei geladene Segmente: .text, .data und .bss, sowie eine Symboltabelle und eine Stringtabelle.
COFF
Das Objektformat von SVR3. Der Header enthält nun eine „Sectiontable“. Man kann also mit mehr als nur den Sections .text, .data und .bss arbeiten.
Der Nachfolger von COFF. Kennzeichnend sind mehrere Sections und mögliche 32-Bit- oder 64-Bit-Werte. Ein wesentlicher Nachteil: ELF wurde auch unter der Annahme entworfen, dass es nur eine ABI (Application Binary Interface) pro Systemarchitektur geben wird. Tatsächlich ist diese Annahme falsch – nicht einmal für die kommerzielle SYSV-Welt (in der es mindestens drei ABIs gibt: SVR4, Solaris, SCO) trifft sie zu.
FreeBSD versucht, dieses Problem zu umgehen, indem ein Werkzeug bereitgestellt wird, um ausführbare Dateien im ELF-Format mit Informationen über die ABI zu versehen, zu der sie passen. Weitere Informationen finden Sie in der Manualpage brandelf(1).
FreeBSD kommt aus dem „klassischen“ Lager
und verwendete traditionell das Format a.out(5), eine
Technik, die bereits über viele BSD-Releases
hinweg eingesetzt und geprüft worden ist. Obwohl es
bereits seit einiger Zeit möglich war, auf einem
FreeBSD-System auch Binaries (und Kernel) im
ELF-Format zu erstellen und
auszuführen, widersetzte FreeBSD sich anfangs dem
„Druck“, auf ELF als
Standardformat umzusteigen. Warum? Nun, als das
Linux-Lager die schmerzhafte Umstellung auf
ELF durchführte, ging es nicht so
sehr darum, dem ausführbaren Format
a.out
zu entkommen, als dem
unflexiblen, auf Sprungtabellen basierten Mechanismus
für „Shared-Libraries“ der die Konstruktion von
Shared-Libraries für Hersteller und Entwickler
gleichermaßen sehr kompliziert machte. Da die
verfügbaren ELF-Werkzeuge eine
Lösung für das Problem mit den Shared-Libraries
anboten und ohnehin generell als „ein Schritt
vorwärts“ angesehen wurden, wurde der Aufwand
für die Umstellung als notwendig akzeptiert und die
Umstellung wurde durchgeführt. Unter FreeBSD ist der
Mechanismus von Shared-Libraries enger an den Stil des
Shared-Library-Mechanismus von Suns SunOS™
angelehnt und von daher sehr einfach zu verwenden.
Ja, aber warum gibt es so viele unterschiedliche Formate?
In alter, grauer Vorzeit gab es simple Hardware.
Diese simple Hardware unterstützte ein einfaches,
kleines System. a.out
war absolut passend
für die Aufgabe, Binaries auf diesem simplen System (eine PDP-11)
darzustellen. Als UNIX® von diesem simplen System portiert
wurde, wurde auch das a.out
-Format beibehalten,
weil es für die frühen Portierungen auf Architekturen
wie den Motorola 68000 und VAX ausreichte.
Dann dachte sich ein schlauer Hardware-Ingenieur,
dass, wenn er Software zwingen könnte, einige
Tricks anzustellen, es ihm möglich wäre, ein
paar Gatter im Design zu sparen, und seinen CPU-Kern
schneller zu machen. Obgleich es dazu gebracht wurde, mit
dieser neuen Art von Hardware (heute als RISC
bekannt) zu arbeiten, war a.out
für
diese Hardware schlecht geeignet. Deshalb wurden viele neue
Formate entwickelt, um eine bessere Leistung auf dieser
Hardware zu erreichen, als mit dem begrenzten, simplen
a.out
-Format. Dinge wie
COFF, ECOFF und
einige andere obskure wurden erdacht und ihre Grenzen
untersucht, bevor die Dinge sich in Richtung
ELF entwickelten.
Hinzu kam, dass die Größe von
Programmen gewaltig wurde und Festplatten sowie
physikalischer Speicher immer noch relativ klein waren.
Also wurde das Konzept von Shared-Libraries geboren. Das
VM-System wurde auch immer fortgeschrittener. Obwohl bei
jedem dieser Fortschritte das
a.out
-Format benutzt worden ist,
wurde sein Nutzen mit jedem neuen Merkmal mehr und mehr
gedehnt. Zusätzlich wollte man Dinge dynamisch zur
Ausführungszeit laden, oder Teile ihres Programms
nach der Initialisierung wegwerfen, um Hauptspeicher
oder Swap-Speicher zu sparen. Programmiersprachen
wurden immer fortschrittlicher und man wollte, dass
Code automatisch vor der main-Funktion aufgerufen wird.
Das a.out
-Format wurde oft
überarbeitet, um alle diese Dinge zu ermöglichen
und sie funktionierten auch für einige Zeit.
a.out
konnte diese Probleme nicht
ohne ein ständiges Ansteigen eines Overheads im Code
und in der Komplexität handhaben. Obwohl
ELF viele dieser Probleme löste,
wäre es sehr aufwändig, ein System umzustellen, das
im Grunde genommen funktionierte. Also musste
ELF warten, bis es aufwändiger war, bei
a.out
zu bleiben, als zu
ELF überzugehen.
Im Laufe der Zeit haben sich die Erstellungswerkzeuge, von denen FreeBSD seine Erstellungswerkzeuge abgeleitet hat (speziell der Assembler und der Loader), in zwei parallele Zweige entwickelt. Im FreeBSD-Zweig wurden Shared-Libraries hinzugefügt und einige Fehler behoben. Das GNU-Team, das diese Programme ursprünglich geschrieben hat, hat sie umgeschrieben und eine simplere Unterstützung zur Erstellung von Cross-Compilern durch beliebiges Einschalten verschiedener Formate usw. hinzugefügt. Viele Leute wollten Cross-Compiler für FreeBSD erstellen, aber sie hatten kein Glück, denn FreeBSD's ältere Sourcen für as und ld waren hierzu nicht geeignet. Die neuen GNU-Werkzeuge (binutils) unterstützen Cross-Compilierung, ELF, Shared-Libraries, C++-Erweiterungen und mehr. Weiterhin geben viele Hersteller ELF-Binaries heraus und es ist gut, wenn FreeBSD sie ausführen kann.
ELF ist ausdrucksfähiger als
a.out
und gestattet eine bessere Erweiterbarkeit
des Basissystems. Die ELF-Werkzeuge werden
besser gewartet und bieten Unterstützung von
Cross-Compilierung, was für viele Leute wichtig ist.
ELF mag etwas langsamer sein, als
a.out
, aber zu versuchen, das zu messen,
könnte schwierig werden. Es gibt unzählige Details, in
denen sich die beiden Formate unterscheiden, wie sie Pages
abbilden, Initialisierungscode handhaben usw. Keins davon
ist sehr wichtig, aber es sind Unterschiede. Irgendwann
wird die Unterstützung für Programme im
a.out
-Format aus dem
GENERIC
-Kernel entfernt werden.
Wenn es dann keinen oder kaum noch
Bedarf für die Unterstützung dieses Formates
gibt, werden die entsprechenden Routinen ganz entfernt
werden.
Wenn Sie Fragen zu FreeBSD haben, schicken Sie eine E-Mail an
<de-bsd-questions@de.FreeBSD.org>.
Wenn Sie Fragen zu dieser Dokumentation haben, schicken Sie eine E-Mail an
<de-bsd-translators@de.FreeBSD.org>.