COS 318: Operating Systems Overview Prof. Margaret Martonosi Computer Science Department Princeton University http://www.cs.princeton.edu/courses/archive/fall11/cos318/ Announcements Precepts: Tue (Tonight)! 7:30pm-8:30pm, 105 CS building Design review: Mon 9/26: 6-9pm, 010 Friend center. Sign up online. Project 1 due: 10/5 at noon! Reminder: Find a project partner and email the pairing to mrm@cs and vivek@cs. (Please cc your partner too, so we… uhhm.. know this is a mutual decision! ) Today Overview of OS structure What does the OS need to do? What other support/functionality does it build on from hardware? Overview of OS components A view from user-level software Pipeline of Creating An Executable File foo.c gcc foo.s as foo.o bar.c gcc bar.s as bar.o ld a.out libc.a … gcc can compile, assemble, and link together Compiler (part of gcc) compiles a program into assembly Assembler compiles assembly code into relocatable object file Linker links object files into an executable For more information: Read man page of elf, ld, and nm Read the document of ELF Execution (Run An Application) On Unix, “loader” does the job Read an executable file Layout the code, data, heap and stack Dynamically link to shared libraries Prepare for the OS kernel to run the application E.g., on Linux, “man ld-linux” Application *.o, *.a ld a.out loader Shared library What’s An Application? Four segments 2n -1 Code/Text – instructions Stack Data – initialized global variables Stack Heap Why? Heap Separate code and data Stack and heap go Initialized data towards each other Code 0 In slightly more detail… 8 Responsibilities Stack Layout by compiler Allocate/deallocate by process creation (fork) and termination Names are relative to stack pointer and entirely local Heap Linker and loader say the starting address Allocate/deallocate by library calls such as malloc() and free() Application program use the library calls to manage Global data/code Compiler allocate statically Compiler emit names and symbolic references Linker translate references and relocate addresses Loader finally lay them out in memory A view from hardware System Organization Processor interrupts Cache Memory Bus I/O Bridge Main I/O Bus Memory Disk Graphics Network Controller Controller Interface Disk Disk Graphics Network System Organization Processor interrupts Cache Memory Bus I/O Bridge Main I/O Bus Memory Disk Graphics Network Controller Controller Interface Graphics Memory Disk Disk Network hierarchy System Organization Processor interrupts Cache Memory Bus I/O Bridge I/O Main I/O Bus Memory Disk Graphics Network Controller Controller Interface Disk Disk Graphics Network Typical Unix OS Structure Application Libraries User level Kernel level Portable OS Layer Machine-dependent layer Typical Unix OS Structure User function calls written by programmers and Application compiled by programmers. Libraries Portable OS Layer Machine-dependent layer Typical Unix OS Structure • Written by elves • Objects pre-compiled • Defined in headers Application • Input to linker • Invoked like functions • May be “resolved” Libraries when program is loaded Portable OS Layer Machine-dependent layer Typical Unix OS Structure Application Libraries Portable OS Layer “Guts” of system calls Machine-dependent layer Software “Onion” Layers Applications User and Kernel Libraries boundary OS Services Device Kernel HW Driver Typical Unix OS Structure Application • Bootstrap • System initialization • Interrupt and exception Libraries • I/O device driver • Memory management • Mode switching Portable OS Layer • Processor management Machine-dependent layer OS’s need to: Manage and switch between processes Manage and protect memory resources Interface and provide safe correct access to I/O devices … How? OS’s need to: (one selected example) Manage and switch between processes What is needed for this? Hw/sw interface issues? Interrupts and Exceptions Change in control flow caused by something other than a jump or branch instruction Interrupt is external event devices: disk, network, keyboard, etc. clock for timeslicing These are useful events, must do something when they occur. Exception is potential problem with program segmentation fault bus error divide by 0 Don’t want my bug to crash the entire machine page fault (virtual memory…) CPU Handling interrupt CPU stops current operation*, saves current program counter and other processor state ** needed to continue at interrupted instruction. Accessing vector table, in memory, it jumps to address of appropriate interrupt service routine for this event. Handler does what needs to be done. Restores saved state at interrupted instruction * At what point in the execution cycle does this make sense? ** Need someplace to save it! Data structures in OS kernel. OS Handling an Interrupt/Exception User Program Invoke specific kernel routine ld Interrupt Handler based on type of interrupt add interrupt/exception handler st mul Must determine what caused RETT beq interrupt ld could use software to examine each sub device bne PC = interrupt_handler Vectored Interrupts PC = interrupt_table[i] kernel initializes table at boot time Clear the interrupt May return from interrupt (RETT) to different process (e.g, context switch) A "Typical" RISC Processor 32-bit fixed format instruction 32 (32,64)-bit GPR (general purpose registers) Status registers (condition codes) Load/Store Architecture Only accesses to memory are with load/store instructions All other operations use registers addressing mode: base register + 16-bit offset Not Intel x86 architecture! x86 Architecture Registers 31 15 8 7 0 16-bit 32-bit 15 0 AH AL AX EAX CS BH BL BX EBX DS CH CL CX ECX SS DH DL DX EDX ES BP EBP FS SI ESI GS DI EDI Segment registers SP ESP General-purpose registers EFLAGS register EIP (Instruction Pointer register) Program Stack Well defined register is stack pointer Stack is used for Frame 0 passing parameters (function, method, procedure, subroutine) storing local variables A stack frame (Activation Record) Frame 1 Return results Frame ptr Return Address Old frame ptr Frame 2 arg1 arg2 stack ptr Local variables First few return results and arguments can be mapped to specific registers (calling conventions) An Execution Context The state of the CPU associated with a thread of control (process) general purpose registers (integer and floating point) status registers (e.g., condition codes) program counter, stack pointer Need to be able to switch between contexts better utilization of machine (overlap I/O of one process with computation of another) timeslicing: sharing the machine among many processes different modes (Kernel v.s. user) Context Switches Save current execution context Save registers and program counter information about the context (e.g., ready, blocked) Restore other context Need data structures in kernel to support this process control block Why do we context switch? Timeslicing: HW clock tick I/O begin and/or end How do we know these events occur? Interrupts... User / Kernel Modes Hardware support to differentiate between what we'll allow user code to do by itself (user mode) and what we'll have the OS do (kernel mode). Mode indicated by status bit in protected processor register. Privileged instructions can only be executed in kernel mode (I/O instructions). Execution Mode What if interrupt occurs while in interrupt handler? Problem: Could lose information for one interrupt clear of interrupt #1, clears both #1 and #2 Solution: disable interrupts Disabling interrupts is a protected operation Only the kernel can execute it user v.s. kernel mode mode bit in CPU status register Other protected operations installing interrupt handlers manipulating CPU state (saving/restoring status registers) Changing modes interrupts system calls (trap instruction) Crossing Protection Boundaries For a user to do something "privileged", it must invoke an OS procedure providing that service. How? System Calls special trap instruction that causes an exception which vectors to a kernel handler parameters indicate which system routine called A System Call User Program Kernel Special Instruction to ld change modes and invoke add Trap st Handler service TA 6 RETT read/write I/O device beq ld create new process sub Service Invokes specific kernel bne Routines routine based on argument kernel defined interface May return from trap to different process (e.g, context switch) RETT, instruction to return to user process CPU Handles Interrupt (with User Code) CPU stops current operation, goes into kernel mode, saves current program counter and other processor state needed to continue at interrupted instruction. Accessing vector table, in memory, jump to address of appropriate interrupt service routine for this event. Handler does what needs to be done. Restores saved state at interrupted instruction. Returns to user mode. Multiple User Programs Sharing system resources requires that we protect programs from other incorrect programs. protect from a bad user program walking all over the memory space of the OS and other user programs (memory protection). protect from runaway user programs never relinquishing the CPU (e.g., infinite loops) (timers). preserving the illusion of non-interruptable instruction sequences (synchronization mechanisms - ability to disable/enable interrupts, special "atomic" instructions). CPU Handles Interrupt (Multiple Users) CPU stops current operation,