Grundlagen der Informatik III

Transkript

1 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 Darmstadt

2 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

3 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

4 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 EXE Datei Loader App1.cpp App2.cpp Compiler Objekt datei Linker Image in MEM Incl.h Objekt datei Fachbereich Informatik Prof. Dr. Frederik Armknecht 4

5 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

6 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

7 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

8 5.1 Beispiel: Interne und externe Referenzen Ref to external symbol exit (defined in libc.so) m.c int e=7; int main() { int r = a(); exit(0); } Ref to external symbol a Def of local symbol ep a.c extern int e; int *ep=&e; int x=15; int y; int a() { return *ep+x+y; } Def of local symbol a Refs of local symbols ep,x,y Ref to external symbol e Defs of local symbols x and y Fachbereich Informatik Prof. Dr. Frederik Armknecht 8

9 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

10 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

11 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

12 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

13 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

14 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

15 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

16 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

17 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

18 5.2 Phasen eines Assemblers Symboltabelle SYMT (Phase 1) Addr. 1: bnez $t0, ELSE Symbol Adresse rel. zum. Segmentanfang Addr. 2: ELSE:. ELSE Addr. 2 (in Schritt 2) Addr. 3: jal SUB SUB 0 undefined Symb. 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) externe Referenz Fachbereich Informatik Prof. Dr. Frederik Armknecht 18

19 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

20 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

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

22 Einordnung des Binders (hier: binden von drei Objekt-Dateien) Fachbereich Informatik Prof. Dr. Frederik Armknecht 23 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.

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

24 5.3 Aufgabe des Binders (noch einmal am Beispiel) Relocatable Object Files Executable Object File system code system data.text.data 0 headers system code main().text m.o a.o main() int e = 7 a() int *ep = &e int x = 15 int y.text.data.text.data.bss a() more system code system data int e = 7 int *ep = &e int x = 15 uninitialized data.symtab.debug.data.bss Fachbereich Informatik Prof. Dr. Frederik Armknecht 25

25 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

26 5.3 Aufgabe des Binders ESTAB m.o main() int e = 7 Import a Symbol main Adresse PADR a() Export a a.o int *ep = &e int x = 15 int y a CSADR + 0 Fachbereich Informatik Prof. Dr. Frederik Armknecht 27

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

28 ESTAB m.o main() int e = 7 Import a M-Eintrag für a Symbol main Adresse PADR a() Export a a.o int *ep = &e int x = 15 int y a CSADR + 0 Text-Eintrag: Befehle aus PADR ff main() speichern unter 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

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

30 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) 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 Fachbereich Informatik Prof. Dr. Frederik Armknecht 31

31 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, <500kB floating point math (sin, cos, tan, log, exp, sqrt, ) % ar -t /usr/lib/libc.a sort fork.o fprintf.o fpu_control.o fputc.o freopen.o fscanf.o fseek.o fstab.o % ar -t /usr/lib/libm.a sort e_acos.o e_acosf.o e_acosh.o e_acoshf.o e_acoshl.o e_acosl.o e_asin.o e_asinf.o e_asinl.o

32 5.4 Klassen von Bindern Binden zur Ladezeit: wie beschrieben Binden vor der Ladezeit: Linkage Editor Binden während der Ausführungszeit: dynamisches Binden Linkage Editor Erzeugen eines gebundenen Programms, das Lademodul, oder Executable Image (executable) Lademodul wird in einer Datei gespeichert Zur Ausführung eines Lademoduls: einfacher Lader reicht aus: aktuelle Startadresse muss nur zu den Relativ-Adressen im Modul addiert werden Fachbereich Informatik Prof. Dr. Frederik Armknecht 33

33 5.4 Klassen von Bindern Dynamisches Binden Ziel: Binden von Unterprogrammen erst zur Laufzeit, beim erstmaligen Aufruf: laden und zum Programm hinzubinden Vorteile: Referenzauflösung on-demand, kein Vorab-Binden einer vollständigen Kopie z.b. einer Bibliothek nötig. Unterstützung des Code-Sharings: ausführfähige Programme nutzen eine einzige Kopie gemeinsam Beispiele: Routinen für die Laufzeit-Unterstützung von C-Programmen in dynamic link library Windows: Dynamic Link Libraries (DLL), laden der DLL on-demand Fachbereich Informatik Prof. Dr. Frederik Armknecht 34

34 Dynamisch gebundene Shared Libraries m.c a.c Translators (cc1, as) Translators (cc1,as) m.o a.o Linker (ld) Partially linked executable p (on disk) p libc.so Shared library of dynamically relocatable object files Fully linked executable p (in memory) Loader/Dynamic Linker (ld-linux.so) P libc.so functions called by m.c and a.c are loaded, linked, and (potentially) shared among processes. Fachbereich Informatik Prof. Dr. Frederik Armknecht 35

35 5.5 Lader (loader) Aufgabe des Laders: Laden eines assemblierten und vom Linker vorbereiteten Objektprogramms vom Sekundärspeicher in den Hauptspeicher Starten der Ausführung (durch Laden des Program Counters mit der Anfangsadresse des Programms) Vier Teilschritte: Allokation (Zuweisung) von Speicherplatz für das Programm (bzw. eines Anfangsstücks bei Paging) ggf. Binden, d.h. Ersetzen logischer Programm-Adressen durch physikalische Hauptspeicher-Adressen Relokation, d.h. Anpassung der adressabhängigen Referenzen an deren aktuelle Position im Hauptspeicher Laden des Programms in den dafür reservierten Bereich Fachbereich Informatik Prof. Dr. Frederik Armknecht 36

36 5.5 Lader (loader) Executable object file ELF header Program header table (required for executables).text section 0 Process image init and shared lib segments Virtual addr 0x080483e0.data section.bss section.symtab.text segment (r/o) 0x rel.text.rel.data.data segment (initialized r/w) 0x0804a010.debug Section header table (required for relocatables).bss segment (uninitialized r/w) 0x0804a3b0 Fachbereich Informatik Prof. Dr. Frederik Armknecht 37

37 5.5 Lader (loader) Varianten: Assemble-and-Go: erweiterter Assembler, der generierten Code direkt im Hauptspeicher ablegt und am Ende von Phase 2 die Ausführung des Codes initiiert Nachteile: Speicherverwaltung mit Segmentierung kann nicht verwendet werden. Programm muss vor jeder Ausführung assembliert werden. Absolutprogramm-Lader: erwartet ein bereits gebundenes Programm, das ab einer vom Programmierer anzugebenden (absoluten) Startadresse in den Hauptspeicher geladen wird. Binden muss vor Aktivität des Laders abgeschlossen sein. Fachbereich Informatik Prof. Dr. Frederik Armknecht 38

38 5.5 Lader (loader) Relativprogramm-Lader: legt Programm nicht ab einer festen, sondern ab einer aktuell verfügbaren Adresse im Hauptspeicher ab. Voraussetzung: Alle Programmadressen sind relativ zum Programmanfang gehalten. Der Lader ersetzt diese dann durch ihren jeweils endgültigen Wert. Relokations-Bits (durch Assembler erzeugt) an Maschinenbefehlen: Lader erkennt daran, dass Befehl zu bearbeiten ist. Dynamischer Lader: steht im Zusammenhang mit dem Paging durch Paging ändert sich i.allg. die Anfangsadresse, d.h. relative Programmadressen müssen über Basis-Register an aktuelle Anfangsadresse angepasst werden. Binden erfolgt also zur Laufzeit. Fachbereich Informatik Prof. Dr. Frederik Armknecht 39