Grundlagen der Informatik III WS 2009 / 2010 [Folien basierend auf VL von Prof. Eckert, WS 07/08, und von Prof. Fellner WS 08/09] Prof. Dr. rer. nat. Frederik Armknecht Sascha Müller Daniel Mäurer Fachbereich Informatik / CASED Mornewegstraße 30 64293 Darmstadt

Gliederung der Vorlesung GdI 3

1. Einführung 2. Assemblerprogrammierung 3. Leistungsbewertung 4. Speicherhierarchie 5. Assembler, Binder, Lader 6. Betriebssysteme und Ein-/Ausgabe (Grundlagen) 7. Rechnernetze (Grundlagen) 8. Compiler (Grundlagen)

Fachbereich Informatik | Prof. Dr. Frederik Armknecht | 2

Gliederung dieses Kapitels

5.0 Überblick 5.1 Assembleraufgaben 5.2 Phasen eines Assemblers 5.3 Binder 5.4 Klassen von Bindern 5.5 Lader (loader)

Fachbereich Informatik | Prof. Dr. Frederik Armknecht | 3

5.0 Überblick • Compiler Frontend: • Parsen der Syntax • Kompilieren in Zwischencode • Compiler Backend und Assembler • Zwischencode -> Native Code • Platzhalter für imports & exports • Linker: • Erzeugen eines executable file • Loader: • Platzieren des Executables im Speicher • I.d.R. Bestandteil des BS Fachbereich Informatik | Prof. Dr. Frederik Armknecht | 4

App1.cpp

App2.cpp

Incl.h

Compiler

Objekt datei

EXE Datei

Loader

Objekt datei

Linker

Image in MEM

5.1 Assembler

Bem: hier nur allgemeine Assembler-Aufgaben, Details hängen stark von der zugrunde liegenden Maschinensprache ab

Definition Assembler Ein Assembler ist ein Programm, das die Aufgabe hat, Assemblerbefehle in Maschinencode zu transformieren, und dabei (1) symbolischen Namen (z.B. Labels) Maschinenadressen zu zuweisen, (2) und eine oder mehrere Objektdatei(en) zu erzeugen.

Fachbereich Informatik | Prof. Dr. Frederik Armknecht | 5

5.1 Assembleraufgaben

Assembler übersetzt Datei in Assemblersprache in Datei mit binären Maschineninstruktionen in zwei Schritten: 1a. Auffinden von Speicherpositionen mit Marken, so dass Beziehungen zwischen symbolischen Namen und Adressen bei Übersetzung von Instruktionen bekannt sind. 1b. Übersetzung jedes Assemblerprogrammbefehls durch Kombination der numerischen Äquivalente der opcodes, Registerbezeichner und Marken in eine legale Instruktion. (2) Assembler erzeugt ein oder mehrere „Objektdateien“, die Maschinen-Instruktionen, Daten und Verwaltungs-Informationen enthält. Eine „Objektdatei“ ist meist nicht ausführbar, da i.Allg. auf Prozeduren oder Daten in anderen Dateien verwiesen wird. Fachbereich Informatik | Prof. Dr. Frederik Armknecht | 6

5.1 Assembleraufgaben

• Marken sind extern (global), falls das markierte Datum

von außen

referenziert werden kann. • Marken sind intern (lokal), falls diese nur innerhalb einer Datei referenzierbar sind. • Der Assembler bearbeitet jede Datei eines Programms separat, d.h. er kennt nur Adressen lokaler Marken. • Erst mit dem Binder (Linker) werden (mehrere) Objekt-Dateien und Bibliotheken zu einem ausführbaren Programm gebunden durch die Behandlung externer Marken.

Fachbereich Informatik | Prof. Dr. Frederik Armknecht | 7

5.1 Beispiel: Interne und externe Referenzen

m.c

a.c

int e=7;

extern int e;

int main() { int r = a(); exit(0); }

int *ep=&e; int x=15; int y;

Ref to external symbol exit Ref to external (defined in symbol a libc.so)

Fachbereich Informatik | Prof. Dr. Frederik Armknecht | 8

Def of int a() { local return *ep+x+y; symbol } ep Def of Refs of local local symbol a symbols ep,x,y

Ref to external symbol e Defs of local symbols x and y

5.1 Assembleraufgaben Problem bei Aufgabe 1: • Nutzen von Marken bevor sie definiert sind Konsequenz: • Abarbeiten des Programms Zeile für Zeile Befehle können Vorwärts-Referenzen enthalten, z.B. bnez $t0, ELSE # Vorwärts-Referenz auf ELSE …. ELSE: ... Problem: Adresse von ELSE ist beim ersten Auftreten unbekannt Konsequenz: korrekter Code kann nicht erzeugt werden Lösung: Assembler macht 2 Läufe (Two-pass) über das Programm • 1-ter Lauf (Phase): Zuordnen von Maschinenadressen • 2-ter Lauf (Phase): Erzeugen des Codes Fachbereich Informatik | Prof. Dr. Frederik Armknecht | 9

5.1 Assembleraufgaben Problem bei Aufgabe 2: Erzeugen der zu ladenden Objektdatei, z.B. .o-Datei Fall 1. • Assembler verwendet absolute Maschinenadressen und eine Objektdatei (Objektprogramm): • dann ist das Laden unmittelbar möglich, ABER: absolut adressiert, d.h. Speicherort muss vorher bekannt sein, • Verschieben des Programms im Speicher ist nicht möglich. Fall 2. • Assembler verwendet relative Adressen und als Eingabe mehrere Programm-Segmente, • Assembler-Ausgabe: ≥ 1 Objekt-Dateien Fachbereich Informatik | Prof. Dr. Frederik Armknecht | 10

5.1 Assembleraufgaben Fall 2 (Forts.) • Adressen werden relativ zu den einzelnen Objektdateien vergeben, • Konsequenz: weitere Transformationsschritte sind notwendig, das ist die Aufgabe des Binder/Laders • Binder/Lader: • Objektdateien zu einem Lademodul zusammenfügen, • Speicherplatz anfordern, • Adressen umrechnen und Objekt-Code laden Frage: woher weiß Binder/Lader was zu tun ist? Antwort: Assembler muss Informationen dafür bereit stellen • Objekt-Datei enthält Klassen von Einträgen (records), die unterschiedliche Informationen für den Binder/Lader zur Verfügung stellen Fachbereich Informatik | Prof. Dr. Frederik Armknecht | 11

5.2 Phasen eines Assemblers Datenstrukturen des Assemblers Ein Assembler benötigt im wesentlichen 2 Tabellen: 1. Tabelle, die eine Zuordnung zwischen Maschinencode und Assemblerbefehl enthält (OCT), statische Tabelle 2. Symboltabelle (SYMT), die eine Zuordnung zwischen symbolischen Namen und Maschinenadressen enthält Für jedes Programm-Segment führt der Assembler 2 Läufe durch: Schritte für Phase 1 eines sehr einfachen Assemblers: 1. Initialisiere Zähler mit Startadresse, falls angegeben, sonst mit 0 2. Ersetze Assemblerbefehl durch seinen Maschinencode unter Verwendung von OCT, z.B. lw durch (35)10 Fachbereich Informatik | Prof. Dr. Frederik Armknecht | 12

5.2 Phasen eines Assemblers 3. Trage symbolischen Namen, der im Befehl auftritt, in Symboltabelle SYMT ein, falls noch nicht in Tabelle 4. Falls eine Marke definierend auftritt: z.B. ELSE: ... • falls Name noch nicht in SYMT: Erzeuge SYMT-Eintrag mit Zählerstand, Zählerstand: Adresse der Marke relativ zum Segmentanfang • falls Marke ohne Zählerstand schon in SYMT: Eintrag des Zählerstands, d.h. Marken-Name ist als Vorwärts-Referenz bereits eingetragen • falls Marke mit Zählerstand schon in SYMT: Fehler: doppelte Namensvereinbarung 5. Erhöhe Zähler um Länge der Instruktion 6. Falls nicht EOF, lies nächste Zeile und gehe zu Schritt 2 Ergebnis von Phase 1: Programm liegt in einer Zwischenform vor. Fachbereich Informatik | Prof. Dr. Frederik Armknecht | 13

5.2 Phasen eines Assemblers Phase 2 Erstellung eines Objekt-Programms für jedes Segment 1. Erzeuge Header-Eintrag und schreibe ihn in Objekt-Programm 2. Initialisiere ersten Text-Eintrag 3. Gehe Zeile für Zeile durch Programm-Segment (= Ergebnis aus Phase 1) 4. Falls symbolischer Name im Befehl auftritt: • suche Name in SYMT, ersetze Name durch Adresse in SYMT • falls Name nicht gefunden: trage 0 als Adresse ein und setze Flag: undefined Symbol (nicht aufgelöste Referenz) 5. Erstelle Maschinenbefehl-Code, füge Code dem Text-Eintrag hinzu 6. Falls noch nicht EOF: lies nächste Zeile des Eingabe-Programms und führe Schritte 3 – 5 durch 7. schreibe letzten Text-Eintrag in Objekt-Programm und 8. schreibe End-Eintrag in Objekt-Programm Fachbereich Informatik | Prof. Dr. Frederik Armknecht | 14

5.2 Phasen eines Assemblers Umgang mit externen Referenzen: • Extern definierte Symbole müssen als importierte Symbole definiert werden, falls sie in einem Segment genutzt werden • Assembler erzeugt anhand dieser Informationen spezielle Einträge in den Objekt-Dateien: • Für zu exportierende Symbole: ein Eintrag (z.B. als (=define)), der den Namen und relative Adresse des Symbols im exportierenden Segment umfasst. • ein Define-Eintrag enthält beispielsweise folgende Infos: Kennung D, exportiertes Symbol, relative Segment-Adresse • Für zu importierende Symbole: ein Eintrag (z.B. als R (=Refer)): Name des importierten Symbols Fachbereich Informatik | Prof. Dr. Frederik Armknecht | 15

5.2 Phasen eines Assemblers • Refer-Eintrag enthält beispielsweise folgende Infos: Kennung R, Name des importierten Symbols • Findet der Assembler eine externe Referenz, so • trägt er in dem erzeugten Code die Adresse 0 ein und • erzeugt einen Modifikations-Eintrag (z.B. als M (=modify)) im Objekt-Programm • Angabe, welches Auftreten der Referenz zu modifizieren (korrekte Adresse nachtragen) ist und • Name des externen Symbols • Modifikations-Eintrag enthält im Wesentlichen folgendes: Kennung M, zu modifizierende Adresse, importiertes Symbol Fachbereich Informatik | Prof. Dr. Frederik Armknecht | 16

5.2 Phasen eines Assemblers Beispiel: Assembler: Erzeugen von Objekt-Dateien (1) Erzeugen von Maschinencode (2) Erzeugen von Informationen für Binder/Lader (3) idR relativ adressierte Objekt-Datei (pro Eingabe-Segment)

Segment 1 … Addr. 1: bnez $t0, ELSE …. Addr. 2: ELSE: Addr. 3: jal SUB …

Symboltabelle SYMT (Phase 1) Symbol Adresse rel. zum Segmentanfang …. ELSE (Addr. 1,2) Addr. 2 (in Phase 2) SUB (Addr. 3) 0 undefined Symb.

Fachbereich Informatik | Prof. Dr. Frederik Armknecht | 17

5.2 Phasen eines Assemblers Addr. 1: bnez $t0, ELSE …. Addr. 2: ELSE: Addr. 3:

jal SUB

Symboltabelle SYMT (Phase 1) Symbol Adresse rel. zum Segmentanfang …. ELSE Addr. 2 (in Schritt 2) SUB 0 undefined Symb. externe Referenz

Phase 2: Code-Erzeugung d.h. erzeugen von Text-Segmenten mit Maschinenbefehlen • Auflösen von Referenzen soweit möglich, z.B. bnez $t0, Addr. 2. • SUB ist externe Referenz: importiertes Symbol in Segment 1 Assembler erzeugt: jal 0 und M-Eintrag im Objektprogramm: M Addr. 3 + SUB d.h. addiere an relativer Adresse Addr. 3 (jal-Befehl) zum Sprungziel 0 die Adresse von SUB (wenn nach dem Binden bekannt) Fachbereich Informatik | Prof. Dr. Frederik Armknecht | 18

5.2 Format von Objekt-Dateien (Unix)

1. „Object file header“ beschreibt Größe und Position der übrigen Abschnitte der Datei. 2. „Text segment“ enthält Programmtext in Maschinensprache, ist u.U. wegen nicht aufgelöster Referenzen nicht ausführbar. 3. „Data segment“ enthält binäre Darstellung der Daten der Quelldatei, u.U. wegen nicht aufgelöster Referenzen nicht vollständig. 4. „Relocation information“ identifiziert Instruktionen und Daten-Worte, die von absoluten Adressen abhängen. Diese Referenzen müssen verändert werden, wenn Teile des Programms im Speicher verschoben (relocated) werden. Fachbereich Informatik | Prof. Dr. Frederik Armknecht | 19

5.3 Binder (linker) Definition Binder Der Binder (engl. linker) hat die Aufgabe, aus einer Menge von einzelnen Modulen ein ausführfähiges Objektprogramm zu erzeugen, indem die noch offenen externen Referenzen aufgelöst werden.

Ausführfähig heißt ausführbar vom Lader (siehe 5.5) Definition Lader Ein Lader (engl. loader) ist ein Systemprogramm, das die Aufgabe hat, Objektprogramme in den Speicher zu laden und ggf. deren Ausführung anzustoßen. Viele Lader beinhalten gleichzeitig Binde-Funktion: Binder/Lader Fachbereich Informatik | Prof. Dr. Frederik Armknecht | 21

5.3 Binder (linker) Binder-Aufgaben: • Kombination aller Objekt-Dateien (Objekt-Module) aller Programmteile und aller benötigten Programm-Bibliotheken zu einem ausführbaren Programm, dem Lademodul • dazu werden die Code- und Datensegment im Speicher verschoben, (relocation) d.h. die Adressbezüge auf Code- und Datenbereiche in den Objekt-Dateien müssen angepasst (resolve) werden • Externe Namensbezüge werden aufgelöst: ersetzen der nicht aufgelösten Referenzen in der Symboltabelle einer Objekt-Datei durch die Adresse der Symbol-Definition • evtl. existierende Bezüge zu Shared-Libaries werden aber erst zur Ladezeit vom Loader aufgelöst: Link-Loader Fachbereich Informatik | Prof. Dr. Frederik Armknecht | 22

Einordnung des Binders (hier: binden von drei Objekt-Dateien)

Linker • durchsucht eine Reihe von Object-Dateien und Programm-Bibliotheken nach der Verwendung von nicht lokalen Routinen, • verbindet diese zu einer einzigen, ausführbaren Datei und löst Referenzen zwischen Routinen in unterschiedlichen Dateien auf. Fachbereich Informatik | Prof. Dr. Frederik Armknecht | 23

5.3 Binder Datenstrukturen und Schritte eines Binders/Laders • Binder benötigt Tabelle (ESTAB), um externe Referenzen aufzulösen: • ein Tabelleneintrag enthält u.a. folgende Infos: Symbol, Adresse, (evtl. in welchem Modul definiert) • PADR: Startadresse für Programm im Speicher i.d.R. durch das Betriebssystem ermittelt und dem Lader mitgeteilt • CSADR (control section adr): Startadresse des jeweils bearbeiteten Moduls

Fachbereich Informatik | Prof. Dr. Frederik Armknecht | 24

5.3 Aufgabe des Binders (noch einmal am Beispiel) Relocatable Object Files system code

.text

system data

.data

Executable Object File 0 headers system code main()

m.o

main()

.text

int e = 7

.data

a()

.text

a.o int *ep = &e .data int x = 15 .bss int y Fachbereich Informatik | Prof. Dr. Frederik Armknecht | 25

.text

a() more system code system data int e = 7 int *ep = &e int x = 15 uninitialized data .symtab .debug

.data .bss

5.3 Aufgabe des Binders

Algorithmus zum Lauf 1 des Binders Jedes Modul wie folgt bearbeiten: 1. Header-Eintrag lesen: Modulname und Startadr. (=CSADR) in ESTAB eintragen, beim ersten Modul gilt: PADR=CSADR 2. Lesen von Export-Einträgen: alle auftretenden Symbole in ESTAB eintragen, ESTAB-Eintrag: Name, Adresse = CSADR + Relativadr 3. Wenn END-Eintrag erreicht: CSADR := CSADR + Länge des Moduls Nach Lauf 1: ESTAB enthält alle externen Symbole und deren Adresse. Fachbereich Informatik | Prof. Dr. Frederik Armknecht | 26

5.3 Aufgabe des Binders

ESTAB m.o

main()

Import a

int e = 7

a()

Symbol main

Adresse PADR

a

CSADR + 0

Export a

a.o int *ep = &e int x = 15 int y

Fachbereich Informatik | Prof. Dr. Frederik Armknecht | 27

5.3 Aufgabe des Binders Algorithmus zum Lauf 2 Laden, Verschieben, Binden 1. Lesen der Text-Einträge aus Objekt-Programm: Abspeichern des Codes an: CSADR + Relativadresse (aus Eintrag) 2. bei Modifikations-Eintrag: suche für Namen die zugehörige Adresse in ESTAB 3. END-Eintrag: Sprung zum Programmstart (z.B. PADR), starten Alternative: Benutzer muss mit einem Execute-Befehle (exec) explizit die Ausführung starten Bem.: Nutzung von Bibliotheksroutinen einfach möglich • Routinen als externe Referenzen deklarieren • Binder/Lader lädt gewünschtes Modul aus der Bibliothek Fachbereich Informatik | Prof. Dr. Frederik Armknecht | 28

ESTAB m.o

main() int e = 7

a()

Import a M-Eintrag für a

Symbol main

Adresse PADR

a

CSADR + 0

Export a

a.o int *ep = &e int x = 15 int y

main() • Text-Eintrag: Befehle aus speichern unter PADR ff • in main: externe Referenz auf a: M-Eintrag beschreibt Stelle im Objekt-Programm, die zu modifizieren ist, Eintragen der absoluten Adresse von a: CSADR

Fachbereich Informatik | Prof. Dr. Frederik Armknecht | 29

5.3 Executable and Linkable Format (ELF) (Standardformat für Object-Programme)  Elf header  Magic number, type (.o, exec, .so), machine, byte ordering, etc.  Program header table  Page size, virtual addresses memory segments (sections), segment sizes.  .text section  Code  .data section  Initialized (static) data  .bss section  “Block Started by Symbol”  Groups data that is not initialized  Doesn’t take up space – only tells how much space is needed  Space is allocated when program is loaded Fachbereich Informatik | Prof. Dr. Frederik Armknecht | 30

ELF header Program header table (required for executables) .text section .data section .bss section .symtab .rel.txt .rel.data .debug Section header table (required for relocatables)

0

5.3 Executable and Linkable Format (ELF)  .symtab section  Symbol table  Procedure and static variable names  Section names and locations  .rel.text section  Relocation info for .text section  Addresses of instructions that will need to be modified in the executable  Instructions for modifying.  .rel.data section  Relocation info for .data section  Addresses of pointer data that will need to be modified in the merged executable  .debug section  Info for symbolic debugging (gcc -g) Fachbereich Informatik | Prof. Dr. Frederik Armknecht | 31

ELF header Program header table (required for executables) .text section .data section .bss section .symtab .rel.text .rel.data .debug Section header table (required for relocatables)

0

5.3 Häufig genutzte Bibliotheken  libc.a (the C standard library)  Ca 1400 Objektdateien (Größe: unter 3 MB), mit ca 200 Standard-(ANSI-) C-Funktionen. Alles andere sind Erweiterungen der GNU C Library wie Netzwerkfunktionen, Systemfunktionen und sogar Kryptographie.  I/O, memory allocation, signal handling, string handling, data and time, random numbers, integer math  libm.a (the C math library): 401 Dateien,