Ausführbares und verknüpfbares Format - Executable and Linkable Format
Dateinamenerweiterung |
none, .axf , .bin , .elf , .o , .prx , .puff , .ko , .mod und .so
|
---|---|
magische Zahl | 0x7F 'E' 'L' 'F' |
Entwickelt von | Unix-Systemlabore |
Formattyp | Binär , ausführbare Datei , Objekt , gemeinsam genutzte Bibliothek , Core-Dump |
Behälter für | Viele ausführbare Binärformate |
In der Berechnung , das Executable and Linking Format ( ELF , früher unter dem Namen Extensible Linking Format ), ist ein gemeinsames Standard - Dateiformat für ausführbare Dateien, Objektcode , gemeinsam genutzte Bibliotheken und Core - Dumps . Zuerst in der Spezifikation für das Application Binary Interface (ABI) der Unix- Betriebssystemversion mit dem Namen System V Release 4 (SVR4) und später im Tool Interface Standard veröffentlicht, wurde es schnell von verschiedenen Anbietern von Unix- Systemen akzeptiert . 1999 wurde es vom 86open- Projekt als Standard-Binärdateiformat für Unix und Unix-ähnliche Systeme auf x86- Prozessoren ausgewählt .
Das ELF-Format ist vom Design her flexibel, erweiterbar und plattformübergreifend . Zum Beispiel unterstützt es verschiedene Endianness- und Adressgrößen, so dass es keine bestimmte Zentraleinheit (CPU) oder Befehlssatzarchitektur ausschließt . Dadurch konnte es von vielen verschiedenen Betriebssystemen auf vielen verschiedenen Hardwareplattformen übernommen werden .
Dateilayout
Jede ELF-Datei besteht aus einem ELF-Header, gefolgt von Dateidaten. Die Daten können umfassen:
- Programmkopftabelle, die null oder mehr Speichersegmente beschreibt
- Abschnittskopftabelle, die null oder mehr Abschnitte beschreibt
- Daten, auf die durch Einträge in der Programmkopftabelle oder Abschnittskopftabelle verwiesen wird
Die Segmente enthalten Informationen, die für die Ausführung der Datei zur Laufzeit benötigt werden, während Abschnitte wichtige Daten zum Verknüpfen und Verschieben enthalten. Jedes Byte in der gesamten Datei kann höchstens einem Abschnitt gehören, und es können verwaiste Bytes vorkommen, die keinem Abschnitt gehören.
00000000 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 |.ELF............|
00000010 02 00 3e 00 01 00 00 00 c5 48 40 00 00 00 00 00 |..>......H@.....|
Beispiel-Hexdump des ELF-Dateiheaders
Dateikopf
Der ELF-Header definiert, ob 32- oder 64-Bit- Adressen verwendet werden. Die Kopfzeile enthält drei Felder, die von dieser Einstellung betroffen sind, und versetzt andere Felder, die ihnen folgen. Der ELF-Header ist 52 bzw. 64 Byte lang für 32-Bit- bzw. 64-Bit-Binärdateien.
Versatz | Größe (Byte) | Gebiet | Zweck | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
32-Bit | 64-Bit | 32-Bit | 64-Bit | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x00 | 4 | e_ident[EI_MAG0] bis e_ident[EI_MAG3] |
0x7F gefolgt von ELF ( 45 4c 46 ) in ASCII ; diese vier Bytes bilden die magische Zahl .
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x04 | 1 | e_ident[EI_CLASS] | Dieses Byte wird entweder auf 1 oder gesetzt 2 , um das 32- bzw. 64-Bit-Format anzuzeigen.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x05 | 1 | e_ident[EI_DATA] | Dieses Byte wird entweder auf 1 oder gesetzt 2 , um Little- bzw. Big- Endianness anzuzeigen . Dies beeinflusst die Interpretation von Multibyte-Feldern, die mit offset beginnen 0x10 .
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x06 | 1 | e_ident[EI_VERSION] | Stellen Sie auf 1 für die ursprüngliche und aktuelle Version von ELF ein.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x07 | 1 | e_ident[EI_OSABI] | Identifiziert das Zielbetriebssystem ABI .
Es wird oft |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x08 | 1 | e_ident[EI_ABIVERSION] | Spezifiziert weiter die ABI-Version. Seine Interpretation hängt vom Ziel-ABI ab. Der Linux-Kernel (nach mindestens 2.6) hat keine Definition davon, daher wird er für statisch gelinkte ausführbare Dateien ignoriert. In diesem Fall sind Offset und Größe von EI_PAD 8 .
glibc 2.12+ falls e_ident[EI_OSABI] == 3 dieses Feld als ABI-Version des dynamischen Linkers behandelt : es definiert eine Liste der Funktionen des dynamischen Linkers, behandelt e_ident[EI_ABIVERSION] als eine vom gemeinsamen Objekt angeforderte Funktionsebene (ausführbar oder dynamisch .) Bibliothek) und verweigert das Laden, wenn ein unbekanntes Merkmal angefordert wird, dh e_ident[EI_ABIVERSION] ist größer als das größte bekannte Merkmal. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x09 | 7 | e_ident[EI_PAD] | derzeit ungenutzt, sollte mit Nullen aufgefüllt werden. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x10 | 2 | e-Typ | Identifiziert den Objektdateityp.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x12 | 2 | e_maschine | Gibt die Architektur des Zielbefehlssatzes an . Einige Beispiele sind:
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x14 | 4 | e_version | Stellen Sie auf 1 für die Originalversion von ELF ein.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x18 | 4 | 8 | e_entry | Dies ist die Speicheradresse des Einstiegspunkts, von dem aus die Ausführung des Prozesses beginnt. Dieses Feld ist je nach dem zuvor definierten Format entweder 32 oder 64 Bit lang. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x1C | 0x20 | 4 | 8 | e_phoff | Zeigt auf den Anfang der Programmkopftabelle. Es folgt normalerweise unmittelbar auf den Dateiheader und macht den Offset 0x34 bzw. 0x40 für ausführbare 32- und 64-Bit-ELF-Dateien.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x20 | 0x28 | 4 | 8 | e_shoff | Zeigt auf den Anfang der Abschnittsüberschriftentabelle. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x24 | 0x30 | 4 | e_flags | Die Interpretation dieses Feldes hängt von der Zielarchitektur ab. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x28 | 0x34 | 2 | e_ehsize | Enthält die Größe dieses Headers, normalerweise 64 Bytes für das 64-Bit- und 52 Bytes für das 32-Bit-Format. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x2A | 0x36 | 2 | e_phentsize | Enthält die Größe eines Programm-Header-Tabelleneintrags. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x2C | 0x38 | 2 | e_phnum | Enthält die Anzahl der Einträge in der Programmkopftabelle. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x2E | 0x3A | 2 | e_shentsize | Enthält die Größe eines Abschnittskopftabelleneintrags. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x30 | 0x3C | 2 | e_shnum | Enthält die Anzahl der Einträge in der Abschnittskopftabelle. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x32 | 0x3E | 2 | e_shstrndx | Enthält den Index des Abschnittskopfzeilen-Tabelleneintrags, der die Abschnittsnamen enthält. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x34 | 0x40 | Ende des ELF-Headers (Größe) |
Programmkopf
Die Programmkopftabelle teilt dem System mit, wie ein Prozessabbild erstellt wird. Es befindet sich am Datei-Offset e_phoff und besteht aus e_phnum- Einträgen, jeder mit der Größe e_phentsize . Das Layout unterscheidet sich bei 32-Bit- ELF und 64-Bit- ELF geringfügig , da sich die p_flags aus Ausrichtungsgründen an einer anderen Strukturposition befinden. Jeder Eintrag ist wie folgt aufgebaut:
Versatz | Größe (Byte) | Gebiet | Zweck | |||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
32-Bit | 64-Bit | 32-Bit | 64-Bit | |||||||||||||||||||||||||||||||||||||||
0x00 | 4 | p_typ | Gibt den Typ des Segments an.
|
|||||||||||||||||||||||||||||||||||||||
0x04 | 4 | p_flags | Segmentabhängige Flags (Position für 64-Bit-Struktur). | |||||||||||||||||||||||||||||||||||||||
0x04 | 0x08 | 4 | 8 | p_offset | Offset des Segments im Dateibild. | |||||||||||||||||||||||||||||||||||||
0x08 | 0x10 | 4 | 8 | p_vaddr | Virtuelle Adresse des Segments im Speicher. | |||||||||||||||||||||||||||||||||||||
0x0C | 0x18 | 4 | 8 | p_paddr | Auf Systemen, bei denen die physikalische Adresse relevant ist, reserviert für die physikalische Adresse des Segments. | |||||||||||||||||||||||||||||||||||||
0x10 | 0x20 | 4 | 8 | p_filesz | Größe in Byte des Segments im Dateibild. Kann 0 sein. | |||||||||||||||||||||||||||||||||||||
0x14 | 0x28 | 4 | 8 | p_memsz | Größe in Byte des Segments im Speicher. Kann 0 sein. | |||||||||||||||||||||||||||||||||||||
0x18 | 4 | p_flags | Segmentabhängige Flags (Position für 32-Bit-Struktur). | |||||||||||||||||||||||||||||||||||||||
0x1C | 0x30 | 4 | 8 | p_align |
0 und 1 geben Sie keine Ausrichtung an. Andernfalls sollte eine positive ganzzahlige Potenz von 2 sein, wobei p_vaddr p_offset modulus p_align gleichsetzt .
|
|||||||||||||||||||||||||||||||||||||
0x20 | 0x38 | Ende des Programmkopfes (Größe). |
Abschnittsüberschrift
Versatz | Größe (Byte) | Gebiet | Zweck | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
32-Bit | 64-Bit | 32-Bit | 64-Bit | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x00 | 4 | sh_name | Ein Offset zu einer Zeichenfolge im Abschnitt .shstrtab , der den Namen dieses Abschnitts darstellt. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x04 | 4 | sh_typ | Gibt den Typ dieses Headers an.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x08 | 4 | 8 | sh_flags | Identifiziert die Attribute des Abschnitts.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x0C | 0x10 | 4 | 8 | sh_addr | Virtuelle Adresse des Abschnitts im Speicher für geladene Abschnitte. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x10 | 0x18 | 4 | 8 | sh_offset | Offset des Abschnitts im Dateibild. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x14 | 0x20 | 4 | 8 | sh_size | Größe in Byte des Abschnitts im Dateibild. Kann 0 sein. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x18 | 0x28 | 4 | sh_link | Enthält den Abschnittsindex eines zugehörigen Abschnitts. Dieses Feld wird je nach Abschnittstyp für verschiedene Zwecke verwendet. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x1C | 0x2C | 4 | sh_info | Enthält zusätzliche Informationen zum Abschnitt. Dieses Feld wird je nach Abschnittstyp für verschiedene Zwecke verwendet. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x20 | 0x30 | 4 | 8 | sh_addralign | Enthält die erforderliche Ausrichtung des Abschnitts. Dieses Feld muss eine Zweierpotenz sein. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x24 | 0x38 | 4 | 8 | sh_entsize | Enthält die Größe jedes Eintrags in Byte für Abschnitte, die Einträge mit fester Größe enthalten. Andernfalls enthält dieses Feld Null. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
0x28 | 0x40 | Ende der Abschnittsüberschrift (Größe) |
Werkzeuge
-
readelf
ist ein binäres Unix-Dienstprogramm, das Informationen über eine oder mehrere ELF-Dateien anzeigt. Eine freie Softwareimplementierung wird von GNU Binutils bereitgestellt . -
elfutils
bietet alternative Tools zu GNU Binutils ausschließlich für Linux. -
elfdump
ist ein Befehl zum Anzeigen von ELF-Informationen in einer ELF-Datei, verfügbar unter Solaris und FreeBSD . -
objdump
bietet eine breite Palette von Informationen über ELF-Dateien und andere Objektformate.objdump
verwendet die Binary File Descriptor-Bibliothek als Back-End, um die ELF-Daten zu strukturieren. - Das Unix-
file
Dienstprogramm kann einige Informationen über ELF-Dateien anzeigen, einschließlich der Befehlssatzarchitektur, für die der Code in einer verschiebbaren, ausführbaren oder gemeinsam genutzten Objektdatei vorgesehen ist oder auf der ein ELF- Core-Dump erstellt wurde.
Anwendungen
Unix-ähnliche Systeme
Das ELF-Format hat ältere ausführbare Formate in verschiedenen Umgebungen ersetzt. Es hat die Formate a.out und COFF in Unix-ähnlichen Betriebssystemen ersetzt:
- Linux
- Solaris / Illumos
- IRIX
- FreeBSD
- NetBSD
- OpenBSD
- Redox
- DragonFly BSD
- Silbe
- HP-UX (außer 32-Bit-PA-RISC-Programme, die weiterhin SOM verwenden )
- QNX Neutrino
- MINIX
Nicht-Unix-Einführung
ELF hat auch eine gewisse Akzeptanz in Nicht-Unix-Betriebssystemen erfahren, wie zum Beispiel:
- OpenVMS , in seinen Itanium- und AMD64- Versionen
- BeOS Revision 4 und höher für x86- basierte Computer (wo es das Portable Executable- Format ersetzte ; die PowerPC- Version blieb beim Preferred Executable Format )
- Haiku , eine Open-Source-Reimplementierung von BeOS
- RISC-Betriebssystem
- Stratus VOS , in PA-RISC- und x86-Versionen
- Windows 10-Jubiläums-Update mit dem Windows-Subsystem für Linux .
- Windows 11
- SkyOS
- Fuchsia OS
- Z/TPF
- HPE NonStop-Betriebssystem
- Deos
Spielekonsole
Einige Spielkonsolen verwenden auch ELF:
- PlayStation Portable , PlayStation Vita , PlayStation (Konsole) , PlayStation 2 , PlayStation 3 , PlayStation 4 , PlayStation 5
- GP2X
- Traumbesetzung
- Spielwürfel
- Nintendo 64
- Wii
- Wii U
PowerPC
Andere (Betriebssysteme) auf PowerPC laufen , die ELF verwenden:
- AmigaOS 4 , die ausführbare ELF-Datei, hat das frühere Extended Hunk Format (EHF) ersetzt, das auf Amigas mit PPC-Prozessor-Erweiterungskarten verwendet wurde.
- MorphOS
- AROS
Mobiltelefone
Einige Betriebssysteme für Mobiltelefone und mobile Geräte verwenden ELF:
- Symbian OS v9 verwendet das E32Image-Format, das auf dem ELF-Dateiformat basiert;
- Sony Ericsson , zum Beispiel des W800i , W610 , W300 , usw.
- Siemens , die SGOLD- und SGOLD2-Plattformen: von Siemens C65 bis S75 und BenQ-Siemens E71/ EL71 ;
- Motorola , zum Beispiel das E398, SLVR L7 , v360, v3i (und alle LTE2-Telefone, auf die der Patch angewendet wurde).
- Bada zum Beispiel das Samsung Wave S8500 .
- Nokia- Telefone oder -Tablets mit Maemo- oder Meego-Betriebssystem, zum Beispiel das Nokia N900 .
- Android verwendet ELF .so (Shared Object)-Bibliotheken für die Java Native Interface . Mit Android Runtime (ART), dem Standard seit Android 5.0 "Lollipop" , werden alle Anwendungen bei der Installation in native ELF-Binärdateien kompiliert.
Einige Telefone können laufen ELF - Dateien durch die Verwendung eines Patches , der hinzufügt Assembler - Code zu der Haupt Firmware , die eine Funktion als bekannt ist ELFPack in der U - Bahn modding Kultur. Das ELF-Dateiformat wird auch mit Atmel AVR (8-Bit), AVR32 und mit Texas Instruments MSP430 Mikrocontroller-Architekturen verwendet. Einige Implementierungen von Open Firmware können auch ELF-Dateien laden, insbesondere die Apple -Implementierung, die in fast allen PowerPC- Maschinen des Unternehmens verwendet wird.
Spezifikationen
- Generisch:
- System V Application Binary Interface Edition 4.1 (1997-03-18)
- System V ABI-Update (Oktober 2009)
- AMD64 :
- ARM :
- IA-32 :
-
IA-64 :
- Itanium Software Conventions and Runtime Guide (September 2000)
-
M32R :
- M32R ELF ABI Ergänzung Version 1.2 (2004-08-26)
- MIPS :
- Motorola 6800 :
-
PA-RISC :
- ELF-Ergänzung für PA-RISC Version 1.43 (6. Oktober 1997)
-
PowerPC :
- System V ABI, PPC-Ergänzung
- PowerPC Embedded Application Binary Interface 32-Bit-Implementierung (1995-10-01)
- 64-Bit PowerPC ELF Application Binary Interface Supplement Version 1.9 (2004)
- SPARC :
- S/390 :
- zSerie :
- Symbian- Betriebssystem 9:
Die Linux Standard Base (LSB) ergänzt einige der obigen Spezifikationen für Architekturen, in denen sie spezifiziert ist. Dies ist beispielsweise bei der System V ABI, AMD64 Supplement, der Fall.
86open
86open war ein Projekt zur Konsensbildung über ein gemeinsames Binärdateiformat für Unix und Unix-ähnliche Betriebssysteme auf der gemeinsamen PC-kompatiblen x86- Architektur, um Softwareentwickler zu ermutigen, auf die Architektur zu portieren. Die ursprüngliche Idee bestand darin, eine kleine Teilmenge von Spec 1170, einem Vorgänger der Single UNIX Specification , und der GNU C Library (glibc) zu standardisieren , um die Ausführung unveränderter Binärdateien auf den x86-Unix-ähnlichen Betriebssystemen zu ermöglichen. Das Projekt wurde ursprünglich als "Spec 150" bezeichnet.
Als Format wurde schließlich ELF gewählt, insbesondere die Linux-Implementierung von ELF, nachdem es sich als De-facto- Standard herausgestellt hatte, der von allen beteiligten Herstellern und Betriebssystemen unterstützt wird.
Die Gruppe begann 1997 mit E-Mail-Diskussionen und traf sich zum ersten Mal am 22. August 1997 in den Büros der Santa Cruz Operation .
Der Lenkungsausschuss war Marc Ewing , Dion Johnson, Evan Leibovitch, Bruce Perens , Andrew Roach, Bryan Wayne Sparks und Linus Torvalds . Weitere Projektbeteiligte waren Keith Bostic , Chuck Cranor, Michael Davidson, Chris G. Demetriou, Ulrich Drepper, Don Dugger, Steve Ginzburg, Jon "maddog" Hall , Ron Holt, Jordan Hubbard , Dave Jensen, Kean Johnston, Andrew Josey, Robert Lipe, Bela Lubkin, Tim Marsland, Greg Page, Ronald Joe Record, Tim Ruckle, Joel Silverstein, Chia-pi Tien und Erik Troan. Vertretene Betriebssysteme und Firmen waren BeOS , BSDI , FreeBSD , Intel , Linux , NetBSD , SCO und SunSoft .
Das Projekt schritt voran und Mitte 1998 begann SCO mit der Entwicklung von lxrun , einer Open-Source- Kompatibilitätsschicht , die Linux-Binärdateien auf OpenServer , UnixWare und Solaris ausführen kann . SCO kündigte offizielle Unterstützung von lxrun bei Linuxworld im März 1999 Sun Microsystems begann Anfang 1999 lxrun für Solaris offiziell unterstützt und später auf die integrierte Unterstützung des Linux - Binär - Format über verschoben Solaris Container für Linux - Anwendungen .
Da die BSDs seit langem Linux-Binärdateien (durch eine Kompatibilitätsschicht ) unterstützten und die wichtigsten x86-Unix-Anbieter das Format unterstützten, entschied das Projekt, dass Linux ELF das von der Industrie gewählte Format sei und "erkläre[d] sich selbst aufgelöst" auf 25. Juli 1999.
FatELF: universelle Binärdateien für Linux
FatELF ist eine Erweiterung im ELF-Binärformat, die Fat-Binärfunktionen hinzufügt . Es richtet sich an Linux und andere Unix-ähnliche Betriebssysteme. Zusätzlich zur Abstraktion der CPU-Architektur ( Bytereihenfolge , Wortgröße , CPU- Befehlssatz usw.) gibt es den potentiellen Vorteil der Software-Plattform-Abstraktion, zB Binärdateien, die mehrere Kernel- ABI- Versionen unterstützen. Ab dem 2. März 2021 ist FatELF nicht mehr in den Mainline-Linux-Kernel integriert.
Siehe auch
- Binäre Schnittstelle der Anwendung
- Vergleich ausführbarer Dateiformate
- DWARF – ein Format zum Debuggen von Daten
- Intel Binärkompatibilitätsstandard
- Portable Executable – von Windows verwendetes Format
- vDSO – virtuelles DSO
- Positionsunabhängiger Code
Verweise
Weiterlesen
- Levine, John R. (2000) [Oktober 1999]. Linker und Loader . Die Morgan Kaufmann Series in Software Engineering and Programming (1 Hrsg.). San Francisco, USA: Morgan Kaufmann . ISBN 1-55860-496-0. OCLC 42413382 . Archiviert vom Original am 2012-12-05 . Abgerufen 2020-01-12 .Code: [1] [2] Errata: [3]
-
Drepper, Ulrich (2006-08-20). "So schreiben Sie gemeinsam genutzte Bibliotheken" (PDF) . 4,0 . Abgerufen 2007-06-20 . Cite Journal erfordert
|journal=
( Hilfe ) - Ein unbesungener Held: Der fleißige ELF von Peter Seebach, 20. Dezember 2005, archiviert vom Original am 24. Februar 2007
- LibElf und GElf - Eine Bibliothek zum Manipulieren von ELf-Dateien an der Wayback-Maschine (archiviert am 25. Februar 2004)
- Das ELF-Objektdateiformat: Einführung , Das ELF-Objektdateiformat von Dissection von Eric Youngdale (1995-05-01)
- Ein Wirbelwind-Tutorial zum Erstellen von Really Teensy ELF-Executables für Linux von Brian Raiter
- ELF-Umzug in nicht verschiebbare Objekte von Julien Vanegue (2003-08-13)
- Embedded ELF Debugging ohne Ptrace vom ELFsh Team (2005-08-01)
- Studie über ELF-Ladung und Relocs von Pat Beirne (1999-08-03)
Externe Links
- FreeBSD-Handbuch: Binäre Formate (archivierte Version)
- FreeBSD elf(5) Handbuchseite
- Häufig gestellte Fragen zu NetBSD ELF
- Linux elf(5) Handbuchseite
- Handbuch zu Oracle Solaris Linker und Bibliotheken
- Das ERESI-Projekt: Reverse Engineering auf ELF-basierten Betriebssystemen
- Linux Today-Artikel auf 86open vom 26. Juli 1999
- Ankündigung von 86open auf der Debian-Announce-Mailingliste 10. Oktober 1997, Bruce Perens
- Erklärung von Ulrich Drepper (PDF) in The SCO Group vs IBM , 19. September 2006
- 86open und ELF-Diskussion zu Groklaw , 13. August 2006