CS 4284 Systems Capstone Linking and Loading Godmar

CS 4284 Systems Capstone Linking and Loading Godmar Back

Today: what you need to know for Project 2 (and life) • Compiling, Linking, Loading – Where are my variables? – How are programs loaded into memory? • Virtual Memory Basics – How are virtual addresses checked and how are they mapped? – What happens on a context-switch with respect to the MMU? CS 4284 Spring 2013

Accessing Information • All information a program reads/writes is stored somewhere in memory • Programmer uses symbolic names: – local variables, global variables, assembly constants • CPU instructions use virtual addresses: – absolute addresses (at 0 x. C 0000024) – relative addresses (at $esp – 16) • Actual memory uses physical addresses: • Big Question: who does the translation & when? CS 4284 Spring 2013

The Big Picture. h Header File 1 Compile Time . h Header File 2 Program Code. c/. cc Source File 1 . h Header File 3 Preprocessor Program Code. c/. cc Source File 2 Compiler Assembly Code. s File 1 Link Time Assembly Code. s File 2 Object Code. o File 1 Object Code. o File 2 Executable Program 1 Load Time Run Time Process 1 Assembler Process 2 Executable Program 2 Loader Process 3 Physical RAM (physically addressed) CS 4284 Spring 2013 Linker MMU

Step 1: Compilation int initialized_variable = 1; int zero_initialized_variable; . comm zero_initialized_variable, 4, 4 int global_function(int argument) { volatile int local_variable = 1; return argument + local_variable + initialized_variable + zero_initialized_variable; } whereismystuff. c . data initialized_variable: . long 1 global_function: pushl %ebp movl %esp, %ebp subl $16, %esp movl $1, -4(%ebp) /* local_variable */ movl -4(%ebp), %eax addl 8(%ebp), %eax /* argument */ addl initialized_variable, %eax addl zero_initialized_variable, %eax leave ret whereismystuff. s • Compiler resolves local variable names (and struct field offsets!) CS 4284 Spring 2013

Step 2: Assembly RELOCATION RECORDS FOR [. text]: OFFSET TYPE VALUE 00000015 R_386_32 initialized_variable 0000001 b R_386_32 zero_initialized_variable global_function: pushl %ebp movl %esp, %ebp subl $16, %esp movl $1, -4(%ebp) /* local_variable */ Contents of section. data: movl <global_function>: -4(%ebp), %eax 0000 01000000. . 0000 addl 55 8(%ebp), %eax /* argumentpush */ 0: %ebp addl 89 initialized_variable, %eax mov %esp, %ebp 1: e 5 addl 83 zero_initialized_variable, %eax 3: ec 10 sub $0 x 10, %esp leave c 7 45 fc 01 00 00 00 movl $0 x 1, 0 xfffffffc(%ebp) 6: ret 8 bwhereismystuff. s d: 45 fc mov 0 xfffffffc(%ebp), %eax 10: 03 45 08 add 0 x 8(%ebp), %eax 13: 03 05 00 00 add 0 x 0, %eax // initialized_variable 19: 03 05 00 00 add 0 x 0, %eax // zero_initialized_variable 1 f: c 9 leave whereismystuff. o 20: c 3 ret CS 4284 Spring 2013

Step 3: Linking 0804837 c <global_function>: 804837 c: 55 804837 d: 89 e 5 804837 f: 83 ec 10 8048382: c 7 45 fc 01 00 00 00 8048389: 8 b 45 fc 804838 c: 03 45 08 804838 f: 03 05 80 95 04 08 8048395: 03 05 88 95 04 08 804839 b: c 9 804839 c: c 3 push mov sub movl mov add add leave ret %ebp %esp, %ebp $0 x 10, %esp $0 x 1, 0 xfffffffc(%ebp), %eax 0 x 8(%ebp), %eax 0 x 8049580, %eax 0 x 8049588, %eax whereismystuff (. exe) • Linker resolves global addresses, stores instructions for loader in executable – Key: linker links multiple, independently assembled. o files into executable – Must decide on layout & then assign addresses & relocate CS 4284 Spring 2013

Step 4: Loading (Conceptual) ELF Header: -start address 0 x 080482 d 8 BSS: • Picture compiler & linker had in mind when building executable - size & start of zero initialized data – sections become segments Data: Contents of section. data: 8049574 00000000 88940408 01000000 MAX_VIRTUAL. . . . Stack Code: 0804837 c <global_function>: 804837 c: 55 804837 d: 89 e 5 804837 f: 83 ec 10 8048382: c 7 45 fc 01 00 00 00 8048389: 8 b 45 fc 804838 c: 03 45 08 804838 f: 03 05 80 95 04 08 8048395: 03 05 88 95 04 08 804839 b: c 9 804839 c: c 3 push %ebp mov %esp, %ebp sub $0 x 10, %esp movl $0 x 1, 0 xfffffffc(%ebp) mov 0 xfffffffc(%ebp), %eax add 0 x 8049580, %eax add 0 x 8049588, %eax leave ret • Executable = set of instructions stored on disk for loader stack segment room for stack to grow room for heap to grow Heap BSS data segment Data Code code segment – consists of sections 0 CS 4284 Spring 2013 start program here

Virtual Memory & Paging (Simplified) MAX_VIRTUAL MAX_PHYSICAL Page Table 0. . 232 -1 range depends on processor architecture range depends on how much RAM you bought MMU IA 32: sizeof(void*)=4 0 pages frames • Maps virtual addresses to physical addresses (indirection) – x 86: page table is called page directory (one per process) – mapping at page granularity (x 86: 1 page = 4 KB = 4, 096 bytes) CS 4284 Spring 2013 0

Step 5: Loading (For Real) FFFF P 1 1 GB C 0400000 3 GB C 0000000 kheap kbss kdata kcode ustack (1) udata (1) ucode (1) 0 kernel heap kernel bss kernel data user stack kernel code after Pintos boots, all physical memory is mapped at Pintos then starts the first user dataand + bss C 0000000 process … up - part already used by kernel useriscode - part is free (but mapped) CS 4284 Spring 2013 free user (1) kernel used

Step 5: Loading (2 nd Process) FFFF P 2 1 GB C 0400000 user stack 3 GB C 0000000 kheap kbss kdata kcode ustack (2) To load a second process, Pintos creates a new page table - clone boot page table - then add entries … udata (2) ucode (2) 0 user data + bss user code CS 4284 Spring 2013 user (2) user (1) kernel free used

Context Switching • Each process has its own address space – This means that the meaning of addresses (say 0 x 08 c 4000) may be different depending on which process is active – Maps to different page in physical memory • When processes switch, address spaces must switch – MMU must be reprogrammed CS 4284 Spring 2013

FFFF P 1 Process 1 Active 1 GB C 0400000 user (2) user (1) kernel 3 GB C 0000000 kheap kbss kdata kcode ustack (1) udata (1) ucode (1) 0 CS 4284 Spring 2013 free used

FFFF P 2 Process 2 Active C 0400000 1 GB access requires kernel mode user (2) user (1) kernel 3 GB C 0000000 kheap kbss kdata kcode ustack (2) udata (2) ucode (2) 0 access possible in user mode CS 4284 Spring 2013 free used

Context Switching intr_entry: (saves entire CPU state) (switches to kernel stack) Process 1 intr_exit: (restore entire CPU state) (switch back to user stack) iret Process 2 user mode kernel mode Kernel switch_threads: (in) (saves caller’s state) (kernel stack switch) CS 4284 Spring 2013 switch_threads: (out) (restores caller’s state)

FFFF P 1 1 GB C 0400000 Process 1 Active in user mode user (2) user (1) kernel 3 GB C 0000000 kheap kbss kdata kcode ustack (1) udata (1) ucode (1) 0 access possible in user mode CS 4284 Spring 2013 free used

Process 1 Active in kernel mode FFFF P 1 C 0400000 1 GB access requires kernel mode kheap kbss kdata kcode ustack (1) } udata (1) ucode (1) 0 void process_activate (void) { struct thread *t = thread_current (); /* Activate thread's page tables. */ pagedir_activate (t->pagedir); 3 GB C 0000000 Context Switch schedule_tail() calls process_activate: user (2) user (1) kernel access possible in user mode CS 4284 Spring 2013 free used

FFFF P 2 C 0400000 Process 2 Active in kernel mode 1 GB access requires kernel mode user (2) user (1) kernel 3 GB C 0000000 kheap kbss kdata kcode ustack (2) udata (2) ucode (2) 0 access possible in user mode CS 4284 Spring 2013 free used

FFFF P 2 1 GB C 0400000 Process 2 Active in user mode user (2) user (1) kernel 3 GB C 0000000 kheap kbss kdata kcode ustack (2) udata (2) ucode (2) 0 access possible in user mode CS 4284 Spring 2013 free used

Summary • All you have to do in Project 2/3/4 is: – Be aware of what memory is currently accessible • Your kernel executes in kernel mode, so you can access all memory (if you use >C 000000 addresses) • But you must set it up such that your programs can run with the memory you allow them to access (at <C 0000000) • Don’t let user programs fool you into accessing other processes’ (or arbitrary kernel) memory – Kill them if they try • Keep track of where stuff is – Virtually (toolchain’s view): • below C 0000000 (PHYS_BASE) user space • above C 0000000 (PHYS_BASE) kernel space – Physically (note: “physical” addresses are represented as 0 x. C 0000000 + phys_addr in Pintos b/c of permanent mapping) CS 4284 Spring 2013