Update to r42604:
Remove the no-longer-relevant section on binary formats.
This commit is contained in:
Bjoern Heidotting
parent
9f1fd7d856
commit
6457f53b95
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=47715
1 changed files with 1 additions and 178 deletions
|
|
@ -5,7 +5,7 @@
|
|||
|
||||
$FreeBSD$
|
||||
$FreeBSDde$
|
||||
basiert auf: r42014
|
||||
basiert auf: r42604
|
||||
-->
|
||||
<chapter xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0" xml:id="basics">
|
||||
<info><title>Grundlagen des UNIX Betriebssystems</title>
|
||||
|
|
@ -60,9 +60,6 @@
|
|||
<listitem>
|
||||
<para>Geräte und Gerätedateien,</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Binärformate unter &os; und</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>wie Sie in den Manualpages nach weiteren Informationen
|
||||
suchen können.</para>
|
||||
|
|
@ -2441,180 +2438,6 @@ Swap: 256M Total, 38M Used, 217M Free, 15% Inuse
|
|||
zugegriffen.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1 xml:id="binary-formats">
|
||||
<title>Binärformate</title>
|
||||
|
||||
<para>Wenn ein Kommando an die Shell übergeben wird, dann wird die
|
||||
Shell die ausführbare Datei in den Speicher laden und einen
|
||||
neuen Prozess erstellen. Ausführbare Dateien sind entweder
|
||||
Binärdateien (die meist vom Linker während der Übersetzung
|
||||
eines Programms erzeugt werden), oder ein Shell-Skript (eine
|
||||
Textdatei, welche von einer Binärdatei, wie &man.sh.1; oder
|
||||
&man.perl.1; interpretiert wird). Das Kommando &man.file.1;
|
||||
kann für gewöhnlich bestimmen, von welchem Typ eine Datei
|
||||
ist.</para>
|
||||
|
||||
<para>Binärdateien benötigen ein klar definiertes Format, damit
|
||||
das System in der Lage ist, sie richtig zu verwenden. Ein Teil
|
||||
der Datei enthält den ausführbaren Maschinencode (Anweisungen
|
||||
die der CPU sagen, was zu tun ist), ein anderer Teil enthält
|
||||
Daten mit vordefinierten Werten, ein weiterer wiederum Daten
|
||||
ohne vordefinierte Werte. Im Laufe der Zeit wurden verschiedene
|
||||
binäre Dateiformate entwickelt.</para>
|
||||
|
||||
<para>Um zu verstehen, warum &os; das Format &man.elf.5; benutzt,
|
||||
müssen zunächst die drei gegenwärtig <quote>dominanten</quote>
|
||||
ausführbaren Formate für &unix; beschrieben werden:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>&man.a.out.5;</para>
|
||||
|
||||
<para>Das älteste und <quote>klassische</quote>
|
||||
Objektformat von &unix; Systemen. Es benutzt einen kurzen,
|
||||
kompakten Header mit einer
|
||||
<foreignphrase>&man.magic.5; number</foreignphrase> am
|
||||
Anfang, die oft benutzt wird, um das Format zu
|
||||
charakterisieren. Es enthält drei geladene Segmente: .text,
|
||||
.data und .bss, sowie eine Symboltabelle und eine
|
||||
Stringtabelle.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para><acronym>COFF</acronym></para>
|
||||
|
||||
<para>Das Objektformat von SVR3. Der Header
|
||||
enthält eine <quote>Sectiontable</quote>, die mehr enthalten
|
||||
kann als nur .text, .data und .bss Sektionen..</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>&man.elf.5;</para>
|
||||
|
||||
<para>Der Nachfolger von <acronym>COFF</acronym>.
|
||||
Kennzeichnend sind mehrere Sections und mögliche
|
||||
32-Bit- oder 64-Bit-Werte. Ein wesentlicher Nachteil ist,
|
||||
dass <acronym>ELF</acronym> unter der Annahme entworfen
|
||||
wurde, dass es nur eine ABI (Application Binary Interface)
|
||||
pro Systemarchitektur geben wird. Tatsächlich ist diese
|
||||
Annahme falsch, denn nicht einmal für die kommerzielle
|
||||
SYSV-Welt (in der es mindestens drei ABIs gibt: SVR4,
|
||||
Solaris, SCO) trifft sie zu.</para>
|
||||
|
||||
<para>&os; versucht dieses Problem zu umgehen, indem
|
||||
ein Werkzeug bereitgestellt wird, um ausführbare
|
||||
Dateien im <acronym>ELF</acronym>-Format mit
|
||||
Informationen über die ABI zu versehen, zu der
|
||||
sie passen. Weitere Informationen finden Sie in
|
||||
&man.brandelf.1;.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<para>&os; kommt aus dem <quote>klassischen</quote> Lager
|
||||
und verwendete traditionell das Format &man.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
|
||||
&os;-System auch Binaries (und Kernel) im
|
||||
<acronym>ELF</acronym>-Format zu erstellen und
|
||||
auszuführen, widersetzte &os; sich anfangs dem
|
||||
<quote>Druck</quote>, auf <acronym>ELF</acronym> als
|
||||
Standardformat umzusteigen. Warum? Nun, als
|
||||
Linux die schmerzhafte Umstellung auf
|
||||
<acronym>ELF</acronym> durchführte, weil der
|
||||
unflexible, auf Sprungtabellen basierte Mechanismus
|
||||
für <quote>Shared-Libraries</quote> der die Konstruktion von
|
||||
Shared-Libraries für Hersteller und Entwickler kompliziert
|
||||
machte. Da die verfügbaren <acronym>ELF</acronym>-Werkzeuge
|
||||
eine Lösung für das Problem mit den Shared-Libraries
|
||||
anboten und generell als <quote>ein Schritt
|
||||
vorwärts</quote> angesehen wurden, wurde der Aufwand
|
||||
für die Umstellung als notwendig akzeptiert und die
|
||||
Umstellung wurde durchgeführt. Unter &os; ist der
|
||||
Mechanismus von Shared-Libraries enger an den Stil des
|
||||
Shared-Library-Mechanismus von &sunos;
|
||||
angelehnt und einfacher zu verwenden.</para>
|
||||
|
||||
<para>Ja, aber warum gibt es so viele unterschiedliche Formate?
|
||||
Damals zu Zeiten der PDP-11, als simple Hardware ein einfaches,
|
||||
kleines System unterstützte, war <filename>a.out</filename>
|
||||
absolut passend für die Aufgabe, Binaries darzustellen. Als
|
||||
&unix; portiert wurde, wurde auch das
|
||||
<filename>a.out</filename>-Format beibehalten, weil es für die
|
||||
frühen Portierungen auf Architekturen wie den Motorola 68k oder
|
||||
die VAX ausreichte.</para>
|
||||
|
||||
<para>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 die CPU
|
||||
schneller zu machen. <filename>a.out</filename> war für diese
|
||||
neue Art von Hardware, bekannt als <acronym>RISC</acronym>,
|
||||
schlecht geeignet. Viele neue Formate wurden entwickelt, um
|
||||
eine bessere Leistung auf dieser Hardware zu erreichen, als mit
|
||||
dem begrenzten, simplen <filename>a.out</filename>-Format.
|
||||
<acronym>COFF</acronym>, <acronym>ECOFF</acronym> und
|
||||
einige andere wurden erdacht und ihre Grenzen
|
||||
untersucht, bevor man sich auf <acronym>ELF</acronym>
|
||||
festgelegt hat.</para>
|
||||
|
||||
<para>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. Die
|
||||
virtuelle Speicherverwaltung wurde auch immer fortgeschrittener.
|
||||
Obwohl bei jedem dieser Fortschritte das
|
||||
<filename>a.out</filename>-Format benutzt worden ist,
|
||||
wurde sein Nutzen mit jedem neuen Merkmal mehr gedehnt.
|
||||
Zusätzlich wollte man Dinge dynamisch zur
|
||||
Ausführungszeit laden, oder Teile eines 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 <filename>a.out</filename>-Format wurde oft
|
||||
überarbeitet, um alle diese Dinge zu ermöglichen
|
||||
und sie funktionierten auch für einige Zeit.
|
||||
<filename>a.out</filename> konnte diese Probleme nicht
|
||||
ohne ein ständiges Ansteigen eines Overheads im Code
|
||||
und in der Komplexität handhaben. Obwohl
|
||||
<acronym>ELF</acronym> viele dieser Probleme löste,
|
||||
wäre es sehr aufwändig, ein System umzustellen, das
|
||||
im Grunde genommen funktionierte. Also musste
|
||||
<acronym>ELF</acronym> warten, bis es aufwändiger war, bei
|
||||
<filename>a.out</filename> zu bleiben, als zu
|
||||
<acronym>ELF</acronym> überzugehen.</para>
|
||||
|
||||
<para>Im Laufe der Zeit haben sich die Erstellungswerkzeuge,
|
||||
von denen &os; seine Erstellungswerkzeuge abgeleitet
|
||||
hat, speziell der Assembler und der Loader, in zwei
|
||||
parallele Zweige entwickelt. Im &os;-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 hinzugefügt. Viele Leute wollten
|
||||
Cross-Compiler für &os; erstellen, aber sie hatten
|
||||
kein Glück, denn &os;'s ältere Sourcen für &man.as.1; und
|
||||
&man.ld.1; waren hierzu nicht geeignet. Die neuen
|
||||
GNU-Werkzeuge (<application>binutils</application>) unterstützen
|
||||
Cross-Compilierung, <acronym>ELF</acronym>, Shared-Libraries und
|
||||
C++-Erweiterungen. Weiterhin geben viele
|
||||
Hersteller <acronym>ELF</acronym>-Binaries heraus und &os;
|
||||
sollte in der Lage sein, diese ausführen.</para>
|
||||
|
||||
<para><acronym>ELF</acronym> ist ausdrucksfähiger als
|
||||
<filename>a.out</filename> und gestattet eine bessere Erweiterbarkeit
|
||||
des Basissystems. Die <acronym>ELF</acronym>-Werkzeuge werden
|
||||
besser gewartet und bieten Unterstützung für Cross-Compilierung.
|
||||
<acronym>ELF</acronym> mag etwas langsamer sein, als
|
||||
<filename>a.out</filename>, 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, oder Initialisierungscode handhaben.</para>
|
||||
</sect1>
|
||||
|
||||
<sect1 xml:id="basics-more-information">
|
||||
<title>Weitere Informationen</title>
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue