1. CS 5204 Operating Systems
Linking and Loading
Godmar Back

2. Today: what you need to know for Project 2
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 5204 Fall 2015

3. 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 0xC )
relative addresses (at $esp – 16)
Actual memory uses physical addresses:
Big Question: who does the translation & when?
CS 5204 Fall 2015

4. Physical RAM (physically addressed)
The Big Picture
.h Header File 1
.h Header File 2
.h Header File 3
Preprocessor
Program Code
.c/.cc Source File 1
Program Code
.c/.cc Source File 2
Compile Time
Compiler
Assembly Code .s File 1
Assembly Code .s File 2
Assembler
Object Code .o File 1
Object Code .o File 2
Link Time
Linker
Executable Program1
Executable Program2
Load Time
Loader
Process1
Process2
Process3
Run Time
MMU
Physical RAM (physically addressed)
CS 5204 Fall 2015

5. Step 1: Compilation
.data
initialized_variable:
.long 1
int initialized_variable = 1;
int zero_initialized_variable;
int global_function(int argument) {
volatile int local_variable = 1;
return argument
+ local_variable
+ initialized_variable
+ zero_initialized_variable; }
.comm zero_initialized_variable,4,4
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.c
whereismystuff.s
Compiler resolves local variable names (and struct field offsets!)
CS 5204 Fall 2015

6. Step 2: Assembly RELOCATION RECORDS FOR [.text]: OFFSET TYPE VALUE
R_386_ initialized_variable
b R_386_ zero_initialized_variable
Contents of section .data:
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
<global_function>:
0: push %ebp
1: 89 e mov %esp,%ebp
3: 83 ec sub $0x10,%esp
6: c7 45 fc movl $0x1,0xfffffffc(%ebp)
d: 8b 45 fc mov 0xfffffffc(%ebp),%eax
10: add 0x8(%ebp),%eax
13: add 0x0,%eax // initialized_variable
19: add 0x0,%eax // zero_initialized_variable
1f: c leave
20: c ret
whereismystuff.o
whereismystuff.s
CS 5204 Fall 2015

7. Step 3: Linking
c <global_function>:
804837c: push %ebp
804837d: 89 e mov %esp,%ebp
804837f: 83 ec sub $0x10,%esp
: c7 45 fc movl $0x1,0xfffffffc(%ebp)
: 8b 45 fc mov 0xfffffffc(%ebp),%eax
804838c: add 0x8(%ebp),%eax
804838f: add 0x ,%eax
: add 0x ,%eax
804839b: c leave
804839c: c ret
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 5204 Fall 2015

8. Step 4: Loading (Conceptual)
Code:
c <global_function>:
804837c: push %ebp
804837d: 89 e mov %esp,%ebp
804837f: 83 ec sub $0x10,%esp
: c7 45 fc movl $0x1,0xfffffffc(%ebp)
: 8b 45 fc mov 0xfffffffc(%ebp),%eax
804838c: add 0x8(%ebp),%eax
804838f: add 0x ,%eax
: add 0x ,%eax
804839b: c leave
804839c: c ret
Data:
Contents of section .data:
ELF Header:
start address 0x080482d8
BSS: - size & start of zero initialized data
Picture compiler & linker had in mind when building executable
sections become segments
MAX_VIRTUAL
Stack
stack segment
room for stack to grow
room for heap to grow
Heap
BSS
data segment
Data
Executable = set of instructions stored on disk for loader
consists of sections
Code
code segment
start program here
CS 5204 Fall 2015

9. Virtual Memory & Paging (Simplified)
MAX_VIRTUAL
MAX_PHYSICAL
Page Table
range
depends on
processor architecture
IA32:
sizeof(void*)=4
range
depends on
how
much
RAM
you
bought
MMU
pages
frames
Maps virtual addresses to physical addresses (indirection)
x86: page table is called page directory (one per process)
mapping at page granularity (x86: 1 page = 4 KB = 4,096 bytes)
CS 5204 Fall 2015

10. Step 5: Loading (For Real)
FFFFFFFF
Step 5: Loading (For Real) P1 C
1 GB
kernel code
kernel data
kernel bss
kernel heap
after Pintos boots, all physical memory is mapped at C and up
- part is already used by kernel
- part is free (but mapped)
kheap
kbss
kdata
free C
kcode
ustack (1)
user stack
user (1)
user (1)
user (1)
kernel
3 GB
kernel
used
kernel
Pintos then starts the first process …
user data + bss
kernel
udata (1)
ucode (1)
user code
CS 5204 Fall 2015

11. Step 5: Loading (2nd Process)
FFFFFFFF
Step 5: Loading (2nd Process) P2 C
1 GB
To load a second process, Pintos creates a new page table
- clone boot page table
- then add entries …
kheap
kbss
user (2)
kdata
user (2)
free C
kcode
user (2)
ustack (2)
user stack
user (1)
user (1)
user (1)
kernel
3 GB
kernel
used
kernel
user data + bss
kernel
udata (2)
ucode (2)
user code
CS 5204 Fall 2015

12. Context Switching Each process has its own address space
This means that the meaning of addresses (say 0x08c4000) 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 5204 Fall 2015

13. Process 1 Active P1 1 GB 3 GB FFFFFFFF C0400000 free C0000000 used
kheap
kbss
user (2)
kdata
user (2)
free C
kcode
user (2)
ustack (1)
user (1)
user (1)
user (1)
kernel
3 GB
kernel
used
kernel
kernel
udata (1)
ucode (1)
CS 5204 Fall 2015

14. Process 2 Active P2 1 GB 3 GB FFFFFFFF C0400000
access possible in user mode
access requires kernel mode
1 GB
kheap
kbss
user (2)
kdata
user (2)
free C
kcode
user (2)
ustack (2)
user (1)
user (1)
user (1)
kernel
3 GB
kernel
used
kernel
kernel
udata (2)
ucode (2)
CS 5204 Fall 2015

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

16. Process 1 Active in user mode
FFFFFFFF
Process 1 Active in user mode P1 C
1 GB
kheap
kbss
user (2)
kdata
user (2)
free C
kcode
user (2)
ustack (1)
user (1)
user (1)
user (1)
kernel
3 GB
kernel
used
kernel
kernel
udata (1)
ucode (1)
access possible in user mode
CS 5204 Fall 2015

17. Process 1 Active in kernel mode
FFFFFFFF
Process 1 Active in kernel mode P1 C
access requires kernel mode
1 GB
Context Switch
schedule_tail() calls process_activate:
void
process_activate (void) {
struct thread *t = thread_current ();
/* Activate thread's page tables. */
pagedir_activate (t->pagedir); }
kheap
kbss
user (2)
kdata
user (2)
free C
kcode
user (2)
ustack (1)
user (1)
user (1)
user (1)
kernel
3 GB
kernel
used
kernel
kernel
udata (1)
ucode (1)
access possible in user mode
CS 5204 Fall 2015

18. Process 2 Active in kernel mode
FFFFFFFF
Process 2 Active in kernel mode P2 C
access requires kernel mode
1 GB
kheap
kbss
user (2)
kdata
user (2)
free C
kcode
user (2)
ustack (2)
user (1)
user (1)
user (1)
kernel
3 GB
kernel
used
kernel
kernel
udata (2)
ucode (2)
access possible in user mode
CS 5204 Fall 2015

19. Process 2 Active in user mode
FFFFFFFF
Process 2 Active in user mode P2 C
1 GB
kheap
kbss
user (2)
kdata
user (2)
free C
kcode
user (2)
ustack (2)
user (1)
user (1)
user (1)
kernel
3 GB
kernel
used
kernel
kernel
udata (2)
ucode (2)
access possible in user mode
CS 5204 Fall 2015

20. 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 addresses)
But you must set it up such that your programs can run with the memory you allow them to access (at <C )
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 (PHYS_BASE) user space
above C (PHYS_BASE) kernel space
Physically (note: “physical” addresses are represented as 0xC phys_addr in Pintos b/c of permanent mapping)
CS 5204 Fall 2015