Date: Sat, 31 Oct 2015 18:02:10 +0000 (UTC) From: Bjoern Heidotting <bhd@FreeBSD.org> To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r47715 - head/de_DE.ISO8859-1/books/handbook/basics Message-ID: <201510311802.t9VI2AFi045104@repo.freebsd.org>
next in thread | raw e-mail | index | archive | help
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>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201510311802.t9VI2AFi045104>