CSE2421 Systems1 Introduction to Low-Level Programming and Computer Organization

Transcription

1 Spring 2013 CSE2421 Systems1 Introduction to Low-Level Programming and Computer Organization Kitty Reeves TWRF 8:00-8:55am 1

2 Compiler Drivers = GCC When you invoke GCC, it normally does preprocessing, compilation, assembly and linking, as needed, on behalf of the user accepts options and file names as operands % gcc O1 -g -o p main.c swap.c % man gcc Pre-processor (cpp).c to.i Compiler (cc1).i file to.s Assembler (as).s to relocatable object file.o Linker (ld) creates executable object file called a.out as default Compiler driver Loader the unix shell invokes a function in the OS to call the loader Copies the code and data in the executable file into memory Transfers control to the beginning of the program See slide #13 and #206 (3 times a charm?!) 2

3 Linkage After the individual source files comprising a program are compiled, the object files are linked together with functions from one or more libraries to form the executable program When the same identifier appears in more than one source file, do they refer to the same entity or to different entities? 3

4 Chp. 7 Linking building a program vs program execution which runs a program i.e. text file EFFICIENCY issue: Small change requires recompilation MODULARITY issue: hard to share common functions (i.e. printf) SOLUTION static LINKER like LAB4 Compile each C program separately to create.o file: % gcc c m.c % gcc c a.c Combined.o files into single executable, then run: % gcc m.o a.o o p % p 4

5 Types of object files Object files, created by the assembler and link editor, are binary representations of programs intended to be executed directly on a processor A relocatable object file holds code and data suitable for linking with other object files to create an executable or a shared object file. Each.o file is produced from exactly one source (.c) file An executable object file (default is a.out) holds code and data that can be copied directly into memory then executed. A shared object file (.so file) is a special type of relocatable object file that can be loaded into memory and linked dynamically, at either load time or run time. Load time: the link editor processes the shared object file with other relocatable and shared object files to create another object file Run time: the dynamic linker combines it with an executable file and other shared objects to create a process image 5

6 Hello World revisited #include <stdio.h> int main() { printf("hello World"); return 0; } Object file has not been linked yet <main>: 0: 55 push %rbp 1: e5 mov %rsp,%rbp 4: bf mov $0x0,%edi 9: b mov $0x0,%eax e: e callq 13 <main+0x13> 13: b mov $0x0,%eax 18: c9 leaveq 19: c3 retq cc <main>: 4004cc: 55 push %rbp 4004cd: e5 mov %rsp,%rbp 4004d0: bf dc mov $0x4005dc,%edi 4004d5: b mov $0x0,%eax 4004da: e8 e1 fe ff ff callq 4003c0 <printf@plt> 4004df: b mov $0x0,%eax 4004e4: c9 leaveq 4004e5: c3 retq Relocatable vs Executable object code 6

7 Static linking What do linkers do? Step 1. Symbol resolution Programs define and reference symbols (variables and functions): void swap() { } swap(); int *xp = &x; // define symbol swap // reference to a symbol swap // define symbol xp, reference x Symbol definitions are stored (by compiler) in a symbol table A symbol table is an array of structs Each entry includes name, size, and location of symbol Linker associates each symbol reference with exactly one symbol definition 7

8 Static linking What do linkers do? Step 2. Relocation Merges separate code and data sections into single sections Relocates symbols from their relative locations in the.o files to their final absolute memory locations in the executable. Updates all references to these symbols to reflect their new positions. 8

9 Object File Format/Organization The object file formats provide parallel views of a file's contents, reflecting the differing needs of those activities ELF header (executable and linkable format) resides at the beginning and holds a road map describing the file's organization. Program header table Tells the system how to create a process image Files used to build a process image (execute a program) must have a program header table; relocatable files do not need one. 9

10 Object File Format/Organization (cont) Section header table Contains information describing the file's sections Every section has an entry in the table each entry gives information such as the section name, the section size, and so on. Sections Hold the bulk of object file information for the linking view: instructions, data, symbol table, relocation information, etc. Files used during linking must have a section header table; other object files may or may not have one. FYI: Although the figure shows the program header table immediately after the ELF header, and the section header table following the sections, actual files may differ. Moreover, sections and segments have no specified order. Only the ELF header has a fixed position in the file. 10

11 ELF Object File Format (details) 11

12 ELF Object File Format (cont) 12

13 Processes (section 8.2) What is a process? Provides each program with the illusion that is has exclusive use of the processor and memory What is a process image? Process address space 13

14 Linker Symbols (reminders) Global symbols Symbols defined by module m that can be referenced by other modules External symbols Global symbols that are referenced by module m but defined by some other module Local symbols Symbols that are defined and referenced exclusively by module m Ex. C functions and variables defined with the static attribute 14

15 Resolving Symbols 15

16 Relocating Code and Data 16

17 Practice problem 7.1 (pg 662) SYMBOL TABLE.symtab Info about functions and global variables that are defined and referenced in a program Does not contain entries for local variables Understanding the relationship between linker symbols and C variables/functions notice that the C local variable temp does NOT have a symbol table entry. Why? It goes on the stack! Symbol swap.o.symtab entry? symbol type module where defined section buf yes extern main.o.data bufp0 yes global swap.o.data bufp1 yes global swap.o.bss swap yes global swap.o.text temp no

18 Swap relocatable symbol table % objdump -r -d -t swap.o swap.o: file format elf32-i386 SYMBOL TABLE: l df *ABS* swap.c l d.text text l d.data data l d.bss bss l O.bss bufp g O.data bufp *UND* buf g F.text swap O = object d = debug l = local F = function f = file g = global 18

19 Symbols and Symbol Tables Local linker symbols!= local program variables.symtab does not contain any symbols that correspond to local non-static program variables. These are managed at run time on the stack and are not of interest to the linker However local procedure variables that are defined with the C static attribute (EXCEPTION) are not managed on the stack The compiler allocates space in.data or.bss for each and created a local linker symbol in the symbol table with a unique name FYI: Static variable s lifetime extends across the entire run of the program where local variables are allocated and deallocated on the stack 19

20 SYMBOL TABLES Built by assemblers using symbols exported by the compiler into the.s file An ELF symbol table is contained in the.symtab section It contains an array of entries where each entry contains: Symbol s value i.e. address Flag bits (l=local, g = global, F=function, etc) Characters and spaces up to 7 bits Section or *ABS* (absolute not in any section) *UND* if referenced but not defined Alignment or size Symbol s name 20

21 Relocation Relocation merges the input modules and assigns runtime addresses to each symbol When an assembler generates an object module, it does not know where the code and data will ultimately be stored in memory or the locations of any externally defined functions or global variables referenced by the module A relocation entry is generated when the assembler encounters a reference to an object who ultimate location is unknown 2 types R_386_PC32 R_386_32 21

22 2 Relocation types R_386_PC32 relocate a reference that uses a 32-bit PC-relative address. Effective address = PC + instruction encoded addr R_386_32 Absolute addressing Uses the value encoded in the instruction 22

23 Relocation Info % gcc -o main -m32 main.c /tmp/ccevreug.o: In function `main': main.c:(.text+0x7): undefined reference to `swap' collect2: ld returned 1 exit status Call offset 0x6, opcode e8, 32-bit ref (-4) Offset = 0x7 Symbol = swap Type = R_386_PC32 % gcc c m32 main.c % objdump -r -tdata main.o SYMBOL TABLE: l df *ABS* main.c l d.text text l d.data data l d.bss bss g O.data buf g F.text main *UND* swap Disassembly of section.text: <main>: 0: 55 push %ebp 0x80483b4 1: 89 e5 mov %esp,%ebp 3: 83 e4 f0 and $0xfffffff0,%esp 6: e8 fc ff ff ff call 7 <main+0x7> 7: R_386_PC32 swap b: b mov $0x0,%eax 10: 89 ec mov %ebp,%esp 12: 5d pop %ebp 13: c3 ret NOTE: relocation entries and instructions are stored in different sections of the object file.rel.txt vs.text.text +.offset 0x80483b4 + 0x7 = 0x80483bb = ref addr 0x80483c8 call swap Relocation entry.symbol swap + 32-bit ref ref addr 0x80483c x80483bb = 0x9 23

24 Executable before/after relocation Return address Location of swap function R_386_PC32 relocate a reference that uses a 32-bit PC-relative address. Effective address = PC + instruction encoded address.text +.offset = 0x x12 = 0x reference address Call + 32-bit ref reference address = 0x80483b x = 0x1a 24

25 Relocation Info.text and.data [0] [1] 25

26 Executable After Relocation and External Reference Resolution 26

27 Relocating Symbols and Resolving External References (another example) 27

28 Relocation information (m.c) 28

29 Relocation information (a.c) 29

30 Executable after relocation with external reference resolution 30