From owner-svn-doc-all@freebsd.org Sat Oct 31 18:02:11 2015 Return-Path: Delivered-To: svn-doc-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7A098A1B0B0; Sat, 31 Oct 2015 18:02:11 +0000 (UTC) (envelope-from bhd@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 537E91224; Sat, 31 Oct 2015 18:02:11 +0000 (UTC) (envelope-from bhd@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id t9VI2Aj0045105; Sat, 31 Oct 2015 18:02:10 GMT (envelope-from bhd@FreeBSD.org) Received: (from bhd@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id t9VI2AFi045104; Sat, 31 Oct 2015 18:02:10 GMT (envelope-from bhd@FreeBSD.org) Message-Id: <201510311802.t9VI2AFi045104@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: bhd set sender to bhd@FreeBSD.org using -f From: Bjoern Heidotting Date: Sat, 31 Oct 2015 18:02:10 +0000 (UTC) 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 X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-all@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "SVN commit messages for the entire doc trees \(except for " user" , " projects" , and " translations" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2015 18:02:11 -0000 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 --> Grundlagen des UNIX Betriebssystems @@ -61,9 +61,6 @@ Geräte und Gerätedateien, - Binärformate unter &os; und - - wie Sie in den Manualpages nach weiteren Informationen suchen können. @@ -2441,180 +2438,6 @@ Swap: 256M Total, 38M Used, 217M Free, 1 zugegriffen. - - Binärformate - - 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. - - 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. - - Um zu verstehen, warum &os; das Format &man.elf.5; benutzt, - müssen zunächst die drei gegenwärtig dominanten - ausführbaren Formate für &unix; beschrieben werden: - - - - &man.a.out.5; - - Das älteste und klassische - Objektformat von &unix; Systemen. Es benutzt einen kurzen, - kompakten Header mit einer - &man.magic.5; number 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. - - - - COFF - - Das Objektformat von SVR3. Der Header - enthält eine Sectiontable, die mehr enthalten - kann als nur .text, .data und .bss Sektionen.. - - - - &man.elf.5; - - Der Nachfolger von COFF. - Kennzeichnend sind mehrere Sections und mögliche - 32-Bit- oder 64-Bit-Werte. Ein wesentlicher Nachteil ist, - dass ELF 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. - - &os; 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 - &man.brandelf.1;. - - - - &os; kommt aus dem klassischen 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 - ELF-Format zu erstellen und - auszuführen, widersetzte &os; sich anfangs dem - Druck, auf ELF als - Standardformat umzusteigen. Warum? Nun, als - Linux die schmerzhafte Umstellung auf - ELF durchführte, weil der - unflexible, auf Sprungtabellen basierte Mechanismus - für Shared-Libraries der die Konstruktion von - Shared-Libraries für Hersteller und Entwickler kompliziert - machte. Da die verfügbaren ELF-Werkzeuge - eine Lösung für das Problem mit den Shared-Libraries - anboten und 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 &os; ist der - Mechanismus von Shared-Libraries enger an den Stil des - Shared-Library-Mechanismus von &sunos; - angelehnt und einfacher zu verwenden. - - 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 a.out - absolut passend für die Aufgabe, Binaries darzustellen. Als - &unix; portiert wurde, wurde auch das - a.out-Format beibehalten, weil es für die - frühen Portierungen auf Architekturen wie den Motorola 68k oder - die 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 die CPU - schneller zu machen. a.out war für diese - neue Art von Hardware, bekannt als RISC, - schlecht geeignet. Viele neue Formate wurden entwickelt, um - eine bessere Leistung auf dieser Hardware zu erreichen, als mit - dem begrenzten, simplen a.out-Format. - COFF, ECOFF und - einige andere wurden erdacht und ihre Grenzen - untersucht, bevor man sich auf ELF - festgelegt hat. - - 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 - a.out-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 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 &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 (binutils) unterstützen - Cross-Compilierung, ELF, Shared-Libraries und - C++-Erweiterungen. Weiterhin geben viele - Hersteller ELF-Binaries heraus und &os; - sollte in der Lage sein, diese ausführen. - - ELF ist ausdrucksfähiger als - a.out und gestattet eine bessere Erweiterbarkeit - des Basissystems. Die ELF-Werkzeuge werden - besser gewartet und bieten Unterstützung für Cross-Compilierung. - 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, oder Initialisierungscode handhaben. - - Weitere Informationen