svn commit: r47715 - head/de_DE.ISO8859-1/books/handbook/basics
Bjoern Heidotting <[email protected]>
| Newsgroups | gmane.os.freebsd.devel.cvs.doc |
|---|---|
| Message-ID | <[email protected]> |
Author: bhd
Date: Sat Oct 31 18:02:10 2015
New Revision: 47715
URL: https://svnweb.freebsd.org/changeset/doc/47715
Log:
Update to r42604:
Remove the no-longer-relevant section on binary formats.
Modified:
head/de_DE.ISO8859-1/books/handbook/basics/chapter.xml
Modified: head/de_DE.ISO8859-1/books/handbook/basics/chapter.xml
==============================================================================
--- head/de_DE.ISO8859-1/books/handbook/basics/chapter.xml Sat Oct 31 17:45:11 2015 (r47714)
+++ head/de_DE.ISO8859-1/books/handbook/basics/chapter.xml Sat Oct 31 18:02:10 2015 (r47715)
@@ -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>
@@ -61,9 +61,6 @@
<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>
</listitem>
@@ -2441,180 +2438,6 @@ Swap: 256M Total, 38M Used, 217M Free, 1
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>
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/svn-doc-all
To unsubscribe, send any mail to "[email protected]"