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$
|
$FreeBSD$
|
||||||
$FreeBSDde$
|
$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">
|
<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>
|
<info><title>Grundlagen des UNIX Betriebssystems</title>
|
||||||
|
|
@ -60,9 +60,6 @@
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>Geräte und Gerätedateien,</para>
|
<para>Geräte und Gerätedateien,</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
<listitem>
|
|
||||||
<para>Binärformate unter &os; und</para>
|
|
||||||
</listitem>
|
|
||||||
<listitem>
|
<listitem>
|
||||||
<para>wie Sie in den Manualpages nach weiteren Informationen
|
<para>wie Sie in den Manualpages nach weiteren Informationen
|
||||||
suchen können.</para>
|
suchen können.</para>
|
||||||
|
|
@ -2441,180 +2438,6 @@ Swap: 256M Total, 38M Used, 217M Free, 15% Inuse
|
||||||
zugegriffen.</para>
|
zugegriffen.</para>
|
||||||
</sect1>
|
</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">
|
<sect1 xml:id="basics-more-information">
|
||||||
<title>Weitere Informationen</title>
|
<title>Weitere Informationen</title>
|
||||||
|
|
||||||
|
|
|
||||||
Loading…
Reference in a new issue