elf(3E) elf(3E)
NAME
elf - Zugriffsbibliothek für Objektdateien
SYNTAX
cc [option ...] datei ... -lelf [bibliothek ...]
#include <libelf.h>
BESCHREIBUNG
Die Funktionen in der ELF-Zugriffsbibliothek ermöglichen einem Pro-
gramm die Bearbeitung von Objektdateien, Archivdateien und Archiv-
Members im ELF-Format (Executable and Linking Format). Die Vorspannda-
tei enthält die Typ- und Funktionsdeklarationen für alle Bibliotheks-
dienste.
Programme kommunizieren mit vielen der Routinen einer höheren Ebene
über einen "ELF-Deskriptor". Wenn das Programm die Arbeit mit einer
Datei aufnimmt, erstellt elfbegin einen ELF-Deskriptor, über den das
Programm die Strukturen und Daten in der Datei bearbeitet. Diese ELF-
Deskriptoren können für den Schreib- und den Lesezugriff auf Dateien
verwendet werden. Nach der Herstellung eines ELF-Deskriptors für eine
Datei kann das Programm Bereichsdeskriptoren abrufen, um die Bereiche
der Datei zu bearbeiten [siehe elfgetscn(3E)]. Bereiche enthalten den
Großteil der tatsächlichen Informationen einer Objektdatei, wie Text,
Daten, die Symboltabelle usw. Ein Bereichsdeskriptor gehört zu einem
bestimmten ELF-Deskriptor genau wie ein Bereich zu einer Datei gehört.
Schließlich stehen über die Bereichsdeskriptoren Datendeskriptoren zur
Verfügung. Diese ermöglichen dem Programm die Bearbeitung der Informa-
tionen, die einem Bereich zugeordnet sind. Ein Datendeskriptor ist
Bestandteil eines Bereichsdeskriptors.
Deskriptoren bieten private Zugriffsmöglichkeiten auf eine Datei und
deren Bestandteile. Anders gesagt ist ein Datendeskriptor einem
Bereichsdeskriptor zugeordnet, der wiederum einem ELF-Deskriptor
zugeordnet ist. Dieser schließlich ist einer Datei zugeordnet. Obwohl
Deskriptoren privat sind, ermöglichen sie den Zugriff auf Dateien, die
für den gemeinsamen Zugriff freigegeben wurden. Angenommen, ein Pro-
gramm verbindet Eingabedateien und verwendet dabei ankommende Daten,
um eine andere Datei zu erstellen oder zu aktualisieren. Ein solches
Programm erhält möglicherweise Datendeskriptoren für einen Eingabe-
und einen Ausgabebereich. Anschließend könnte es den Ausgabedeskriptor
aktualisieren, so daß dieser die Daten des Eingabedeskriptors erneut
verwendet. Die Deskriptoren sind also unterschiedlich, könnten aber
dennoch gemeinsam auf die zugeordneten Datenbyte zugreifen. Durch den
gemeinsamen Zugriff werden der durch doppelte Puffer entstehende Spei-
cherplatzbedarf sowie der durch das unnötige Kopieren von Daten
erzeugte zusätzliche Systemaufwand vermieden.
Seite 1 Reliant UNIX 5.44 Gedruckt 11/98
elf(3E) elf(3E)
DATEIKLASSEN
ELF bietet einen Rahmen, in dem eine Familie von Objektdateien defi-
niert werden kann, und unterstützt dabei mehrere Prozessoren und
Architekturen. Ein sehr wichtiges Unterscheidungsmerkmal von Objektda-
teien ist die Klasse, d. h. Kapazität, einer Datei. Die 32-Bit-Klasse
unterstützt Architekturen, in denen ein 32-Bit-Objekt, wie im folgen-
den Beispiel gezeigt, Adressen oder Dateigrößen darstellen kann:
_____________________________________________________
| Name | Zweck |
|||
| Elf32Addr | Vorzeichenlose Adresse |
| Elf32Half | Vorzeichenlose mittelgroße Ganzzahl|
| Elf32Off | Vorzeichenloses Datei-Offset |
| Elf32Sword | Vorzeichenbehaftete große Ganzzahl |
| Elf32Word | Vorzeichenlose große Ganzzahl |
| unsigned char| Vorzeichenlose kleine Ganzzahl |
|______________|_____________________________________|
Andere Klassen werden den Anforderungen entsprechend so definiert, daß
sie größere (oder kleinere) Rechner unterstützen. Einige Bibliotheks-
dienste bearbeiten nur Datenobjekte für eine bestimmte Klasse, während
andere Dienste klassenunabhängig sind. Zur Verdeutlichung dieses
Unterschieds spiegeln die Namen der Bibliotheksfunktionen den Status
der Funktion wider. Dies wird im folgenden beschrieben.
DATENDARSTELLUNGEN
Vom Konzept her unterstützen zwei parallele Objektgruppen rechnerüber-
greifende Übersetzungsumgebungen. Eine Gruppe entspricht dem Dateiin-
halt, während die andere Gruppe dem rechnereigenen Speicherabbild des
Programms entspricht, das die Datei bearbeitet. In den Include-Dateien
enthaltene Typendefinitionen funktionieren auf dem systemeigenen Rech-
ner, für den möglicherweise andere Datencodierungen (Größe oder Byte-
folge) gelten als für den Zielrechner. Systemeigene Speicherobjekte
sollten zur Vermeidung von Informationsverlusten zwar mindestens so
groß sein wie die Dateiobjekte, sie können jedoch auch größer sein als
die Dateiobjekte, wenn dies eher dem Konzept des Host-Rechners ent-
spricht.
Für die Konvertierung zwischen Datei- und Speicherdarstellungen stehen
Übersetzungsfunktionen zur Verfügung. Einige Bibliotheksroutinen kon-
vertieren Daten automatisch, während andere die Konvertierung dem Pro-
gramm überlassen. In beiden Fällen müssen Programme, die Objektdateien
erstellen, Dateitypenobjekte in diese Dateien schreiben. Programme,
die Objektdateien lesen, benötigen eine ähnliche Ausgangsbasis. Wei-
tere Informationen finden Sie unter elfxlate(3E) und elffsize(3E).
Seite 2 Reliant UNIX 5.44 Gedruckt 11/98
elf(3E) elf(3E)
Programme können Daten explizit übersetzen und dabei die vollständige
Steuerung des Layouts und der Semantik der Objektdatei übernehmen.
Wenn für das Programm günstiger ist, nicht die vollständige Steuerung
zu übernehmen, stellt die Bibliothek eine Schnittstelle der höheren
Ebene zur Verfügung, die zahlreiche Details der Objektdatei verdeckt.
elfbegin und zugehörige Funktionen ermöglichen einem Programm die
Arbeit mit systemeigenen Speichertypen, indem sie beim Lese- oder
Schreibzugriff auf eine Objektdatei automatisch die Konvertierung vom
Speicherobjekt zur entsprechenden Datei und umgekehrt durchführen.
ELF-VERSIONEN
Objektdateiversionen ermöglichen ELF die Anpassung an neue Anforderun-
gen. Drei unabhängige Versionen können für ein Programm von Bedeutung
sein. Erstens erkennt ein Anwendungsprogramm eine bestimmte Version,
da es mit bestimmten Include-Dateien kompiliert wurde. Zweitens ist
die Zugriffsbibliothek in ähnlicher Weise mit Include-Dateien kompi-
liert, die festlegen, welche Versionen die Bibliothek interpretieren
kann. Drittens enthält eine ELF-Objektdatei einen Wert, der ihre Ver-
sion angibt. Dieser Wert wird durch die, dem Ersteller der Datei
bekannten ELF-Version festgelegt.
Im Idealfall stimmen alle drei Version überein. Sie können jedoch auch
unterschiedlich sein.
- Ist die Version des Programms neuer als die der Zugriffsbibliothek,
verwendet das Programm möglicherweise Informationen, die der Bibli-
othek unbekannt sind. Übersetzungsroutinen funktionieren dann even-
tuell nicht korrekt, und das Ergebnis kann ein undefiniertes Ver-
halten sein. In diesem Fall muß eine neue Bibliothek installiert
werden.
- Die Version der Bibliothek kann neuer sein als die des Programms
und der Datei. Die Bibliothek versteht die alten Versionen, so daß
es in diesem Fall keine Kompatibilitätsprobleme gibt.
- Schließlich kann die Version einer Datei so neu sein, daß weder das
Programm noch die Bibliothek diese Version erkennen. Das Programm
ist möglicherweise nicht in der Lage, die Datei korrekt zu verar-
beiten. Dies hängt davon ab, ob die Datei zusätzliche Informationen
enthält und diese ohne Schwierigkeiten ignoriert werden können.
Auch in diesem Fall ist am sichersten, eine neue Bibliothek zu
installieren, die die Version der Datei versteht.
Seite 3 Reliant UNIX 5.44 Gedruckt 11/98
elf(3E) elf(3E)
Ein Programm muß seine Version mit elfversion an die Bibliothek über-
geben, damit die genannten Unterschiede berücksichtigt werden können.
Es erstellt auf diese Weise eine "Arbeitsversion" für den Prozeß. Die
Bibliothek verwendet diese Version und akzeptiert Daten vom Programm
bzw. stellt dem Programm Daten in der richtigen Weise dar. Beim Lesen
von Objektdateien verwendet die Bibliothek zum Interpretieren der
Daten die Version der jeweiligen Datei. Beim Schreiben von Dateien
oder Konvertieren von Speichertypen in die entsprechenden Dateien ver-
wendet die Bibliothek die Arbeitsversion des Programms für die Datei-
daten.
SYSTEMDIENSTE
Es wurde bereits erwähnt, daß elfbegin und die zugehörigen Routinen
ELF-Dateien eine Schnittstelle der höheren Ebene zur Verfügung stel-
len, so daß E/A-Operationen für das Anwendungsprogramm durchgeführt
werden können. Diese Routinen gehen davon aus, daß ein Programm kom-
plette Dateien ohne expliziten Einsatz temporärer Dateien im Speicher
halten kann. Wenn Bibliotheksroutinen eine Datei lesen, stellen sie
die Daten in den Speicher und führen nachfolgende Operationen an der
Kopie im Speicher durch. Programme, die mit diesem Verfahren große
Objektdateien lesen und schreiben wollen, müssen auf einem Rechner mit
einem großen virtuellen Adreßbereich für Prozesse ausgeführt werden.
Wird die Anzahl der Dateien, die gleichzeitig geöffnet sein können,
durch das zugrundeliegende Betriebssystem eingeschränkt, kann ein Pro-
gramm mit elfcntl alle erforderlichen Daten aus der Datei abrufen, so
daß der Dateideskriptor anschließend geschlossen und neu verwendet
werden kann.
Die elfbegin-Schnittstellen können zwar von vielen Programmen auf
bequeme und effiziente Weise genutzt werden, sind aber dennoch mögli-
cherweise für einige Programme nicht geeignet. In solchen Fällen kann
eine Anwendung die Datenübersetzungsroutinen elfxlate direkt aufru-
fen. Diese Routinen führen keine Ein- oder Ausgabe durch, sondern
überlassen dies der Anwendung. Da die Anwendung einen größeren Teil
des Jobs übernimmt, steuert sie ihr eigenes Ein- und Ausgabemodell.
BIBLIOTHEKENNAMEN
Die der Bibliothek zugeordneten Namen haben verschiedene Formate.
elfname Diese klassenunabhängigen Namen führen für das Pro-
gramme einige Dienste name aus.
elf32name Dienstnamen mit einer integrierten Klasse, in diesem
Fall 32 geben an, daß sie nur für die angegebene
Dateiklasse funktionieren.
ElfType Datentypen können ebenfalls klassenunabhängig sein und
unterscheiden sich durch die Typangabe Type.
Seite 4 Reliant UNIX 5.44 Gedruckt 11/98
elf(3E) elf(3E)
Elf32Type Klassenabhängige Datentypen verfügen über einen einge-
betteten Klassennamen, in diesem Fall 32.
ELFCCMD Einige Funktionen verwenden Kommandos, die ihre Aktio-
nen steuern. Diese Werte sind Bestandteil der Aufzäh-
lung ElfCmd und liegen im Bereich von null bis
ELFCNUM-1.
ELFFFLAG Einige Funktionen verwenden Optionen, die den Bibliot-
heksstatus und/oder Bibliotheksaktionen steuern.
Optionen sind Bit, die kombiniert werden können.
ELF32FSZTYPE Diese Konstanten geben die Dateigrößen in Byte der
ELF-Grundtypen für die 32-Bit-Klasse von Dateien an.
Weitere Informationen finden Sie unter elffsize(3E).
ELFKKIND Die Funktion elfkind gibt die Art KIND der Datei an,
die einem ELF-Deskriptor zugeordnet ist. Diese Werte
sind Bestandteil der Aufzählung ElfKind und liegen im
Bereich von null bis ELFKNUM-1.
ELFTTYPE Bearbeitet eine Dienstfunktion wie elfxlate mehrere
Typen, geben Namen in diesem Format den gewünschten
Typ TYPE an. ELFTEHDR beispielsweise gehört also
direkt zu Elf32Ehdr. Diese Werte sind Bestandteil der
Aufzählung ElfType und liegen im Bereich von null bis
ELFTNUM-1.
HINWEISE
Die Informationen in den ELF-Include-Dateien sind in allgemeine und
prozessorspezifische Daten unterteilt. Ein Programm kann die Informa-
tionen eines Prozessors durch Einbetten der entsprechenden Include-
Datei zur Verfügung stellen: <sys/elfNAME.h>. Dabei entspricht NAME
dem Prozessornamen, wie er im ELF-Dateivorspann verwendet wird.
_________________________
| Symbol| Prozessor |
|||
| M32 | AT&T WE 32100 |
| SPARC | SPARC |
| 386 | Intel 80386 |
| 486 | Intel 80486 |
| 860 | Intel 80860 |
| 68K | Motorola 68000|
| 88K | Motorola 88000|
| R2000 | MIPS R2000 |
|_______|________________|
Seite 5 Reliant UNIX 5.44 Gedruckt 11/98
elf(3E) elf(3E)
Andere Prozessoren können gegebenenfalls der Tabelle hinzugefügt wer-
den. Ein Programm kann beispielsweise mit folgendem Code die prozes-
sorspezifischen Informationen für den Prozessor MIPS R2000 anzeigen.
#include <libelf.h>
#include <sys/elfR2000.h>
Ohne die Definition der Include-Datei <sys/elfR2000.h> wären nur die
allgemeinen ELF-Informationen sichtbar.
SIEHE AUCH
elfbegin(3E), elfcntl(3E), elfend(3E), elffill(3E), elfflag(3E),
elffsize(3E), elfgetarhdr(3E), elfgetarsym(3E), elfgetbase(3E),
elfgetdata(3E), elfgetehdr(3E), elfgetident(3E), elfgetphdr(3E),
elfgetscn(3E), elfgetshdr(3E), elfhash(3E), elfkind(3E),
elfnext(3E), elfrand(3E), elfrawfile(3E), elfstrptr(3E),
elfupdate(3E), elfversion(3E), elfxlate(3E), a.out(4), ar(4).
Seite 6 Reliant UNIX 5.44 Gedruckt 11/98