1. OPERATING SYSTEMS COURSE THE HEBREW UNIVERSITY SPRING 2015 1 Exercise1 Introduction & Interrupts

2. Exercise plan 2 1. Administrations 2. Interrupts – internal and external (exceptions and traps) 3. Working with System Calls

3. מנהלות מנהלה 3

4. שעות קבלה דרור פייטלסון – שני 11:00-12:00 311A אלקנה בריס – רביעי 10:00 - 9:00 B2XX נתנאל זכאי – שני 12:00-13:00 A306  בתאום מראש במייל הקורס! 4

5. מנהלות 5 תרגילים – חובה לעבור בכולם. התרגילים יכללו שאלות תאורטיות ומשימות תכנותיות. האתר www.cs.huji.ac.il/~os, עיינו בנהלים בקפידה.www.cs.huji.ac.il/~osבנהלים שימוש ב-moodle לצורך הודעות, שאלות, פורום תלמידים, הגשות וכו'. כתובת הדואר של הקורס os@cs.huji.ac.il 5

6. Course Motivation (1) 6 What happens when you press a button? What happens when you use “write” or “read” of a file? What does “segmentation fault” mean? How the memory and hard-disk are managed (from the software point of view)?  How can we run programs that uses more memory that we actually have?  Reading a file is extremely slow, how the computer keep being responsive? What is it the Internet network? How does it work?

7. Course Motivation (2) 7 How can speed up our programs using multi-core system?  There are a few main problems arise from this, we will study how to solve them. Protocols to send messages between different computers over the Internet Network.

8. Computer Hardware 8

9. ) CPU (Central Processing Unit 9 Can use only data that is stored in registers (not memory) Executes a set of instructions:  Data handling – set a register, store,read  Arithmetic operations - Bitwise operations, compare, and basic mathematics operations.  Control flow – branch, conditional branch Each instruction is represented by a unique binary number.

10. Typical Memory Hierarchy 8MB 8GB2TB Current Size 168FP 168 INT 10

11. Memory Hierarchy Main Memory - located on chips inside the computer (outside CPU). The program instructions and the processes’ data are kept in main memory. External Memory - disk. Information stored on a disk is not deleted when the computer turned off. The main memory has less storage capacity than the hard disk. The hard disk can write and read information to and from the main memory. The access speed of main memory is much faster than a hard disk. Programs are stored on the disk until they are loaded into memory, and then use the disk as both the source and destination of the information for their processing. 11

12. User Mode and Kernel Mode 12

13. Definitions: process & kernel A process is an executing instance of a program.  An active process is a process that is currently advancing in the CPU (while other processes are waiting in memory for their turns to use the CPU). The kernel is the core of the operating system and it has complete control over everything that happens in the system. The kernel is trusted software, but all other programs are considered untrusted software. The CPU can be in kernel mode or in user mode. When the CPU is in kernel mode, it is assumed to be executing trusted software, and thus it can execute any instructions and reference any memory addresses. 13

14. Definitions: CPU user & kernel mode User mode is a non-privileged mode in which processes are forbidden to access those portions of memory that have been allocated to the kernel or to other programs. When a user mode process wants to use a service that is provided by the kernel (e.g. a system call), the system must switch temporarily into kernel mode. Code running in kernel mode has access to key system resources. The entire kernel, which is not a process but a controller of processes, executes only in kernel mode. When the kernel has satisfied the request by a process, it returns the processor to user mode. 14

15. Definitions: system calls & IO A system call is a request to the kernel in an operating system by an active process for a service performed by the kernel. Input/Output (I/O) is any program, operation or device that transfers data to or from a peripheral device (such as disk drives, keyboards, mice and printers). 15

16. Interrupt 16

17. External Interrupts: Motivation Much of the functionality embedded inside a computer is implemented by hardware devices other than the processor. Since each device operates at its own pace, a method is needed for synchronizing the operation of the processor with these devices.  For example, what you happen if we would try to read a file and immediately after that use the information? 17

18. One solution is for the processor to sit in a tight loop, asking each device about its current state. When data is available in one of the devices, the processor can then read and process the incoming bytes. This method works but it has two main disadvantages: I. Wasteful in terms of processing power - the processor is constantly busy reading the status of the attached devices instead of executing some useful code. II. When the rate of data transfer is extremely high, the processor might lose data bytes arriving from the hardware devices. External Interrupts: Motivation 18

19. External Interrupts : Solution Instead of polling hardware devices to wait for their response, each device is responsible for notifying the processor about its current state. When a hardware device needs the processor's attention, it simply sends an electrical signal (external interrupt) through a dedicated pin in the interrupt controller chip (located on the computer's motherboard). 19

20. The Interrupt Controller The interrupt controller serves as an intermediate between the hardware devices and the processor. The interrupt controller has several input lines that take requests from the different devices. Its responsibility is to alert the processor when one of the hardware devices needs its immediate attention. The controller passes the request to the processor, telling it which device issued the request (which interrupt number triggered the request). 20

21. Definitions: Interrupts Processes can be interrupted by two types of interrupts: External Interrupt and Internal Interrupt Internal interrupts may be exceptions or traps. An interrupt may be Maskable Interrupt that can be ignored or Non-maskable Interrupt that can’t. 21

22. External Interrupt An External interrupt is a signal to the CPU indicating that an event has occurred, and it results in changes in the sequence of instructions that is executed by the CPU. Interrupts are events which aren’t part of the running program’s regular, pre-planned code. Caused by an external event which typically needs routine attention. For example:  User pressed a key on the keyboard.  User sneezed, causing mouse to move.  Disk drive has data that was requested 20 ms ago.  Timer (used by the OS as an alarm clock) expired. E.g., when several programs running simultaneously. 22

23. Dealing with Interrupts Interrupt handling is like dealing with a function call, with the hardware calling a function (“handler”) to deal with it. Hence, we need to save the state as it was when the interruption happened, handle the interruption, and then return to the state as it was. Combination of hardware & software is necessary to deal with interrupts. 23

24. The basic mechanism Similar to a function call: 1. Getting the interrupt 2. Saving current state 3. Transfer control & service the request 4. Previous state is restored 5. Return control 24

25. (1) Getting the Interrupt External event interrupts the main program execution. An electronic signal is provided to the processor - indicating the need to handle an interrupt request. This signal is only recognized at the end of the instruction cycle loop (after the current instruction has been processed, but before the next instruction is "fetched" from memory). 25

26. (2) Saving Current State Before an interrupt can be serviced, the processor must save its current status. Servicing an interrupt is like performing a subroutine call. One of the most critical pieces of information that must be saved is the value of the Program Counter (i.e. the location of the next instruction to be performed after servicing of the interrupt is complete). Processing an interrupt request involves performing a series of instructions for that request. This tends to modify the contents of registers, so the registers also need to be saved. 26

27. (3) Transfer control & service the request CPU checks which device sent the interrupt request. The processor determines where to find the necessary instructions needed to service that specific request (typically handled using a "interrupt vector" which contains interrupt device numbers and the addresses of service subroutines for each interrupt number).  The interrupt vector is stored at a predefined memory location 0 27

28. (4) Previous State is Restored As a final step in each service routine, all register values, including the Program Counter, must be restored to their original values as they were just before the interrupt occurred. 28

29. (5) Return control Control is returned to the interrupted program The next instruction is pointed by the program counter Back to user mode! 29

30. Example Assume we run the following program:  add r1, r2, r3  sub r3, r4, r5  and r5, r3, r6 As execution reaches code above, a user sneezes  moving mouse  triggering an interrupt. Based on time of sneeze (in the middle of sub), hardware completes add and sub, but squashes xor (for now). The handler starts:  The screen pointer (the little arrow) is moved The handler finishes Execution resumes with xor. 30

31. Interrupt as APC Can also be characterized as an "asynchronous procedure call" The interrupt is asynchronous, as the program can’t control it. The interrupt is effectively invisible to the interrupted program. 31

32. Internal Interrupts 32 Until now we saw how we handle external interrupt. We handle Internal interrupt in the same way, except the first step of getting the interrupt.  The CPU creates the interrupt. The mechanism is therefore: 1. Saving current state 2. Transfer control & service the request 3. Previous state is restored 4. Return control

33. Exceptions Exceptions - similar to HW interrupt, but not caused by an external source, but during the program execution when errors occur. Examples:  Division by zero  Segmentation fault  Privileged instruction  Invalid instruction  Page fault 33

34. Exceptions When an exception occurs, the address of the instruction which generated the exception is saved. Then the OS gives the exception handler a chance to fix the problem.  The exception handler may be owned by the process. If there was an handler, the program is restarted at the address of the fault and continue normally Otherwise, the program is aborted. 34

35. Page Fault Example A program requests data that is not currently in real memory. An exception triggers the operating system to fetch the data from the disk and load it into main memory. The program gets its data without even knowing that an exception has occurred. The program continue with the same instruction. 35

36. Trap A trap is similar to an exception, in that it occurs in the usual run of the program, but unlike it, it is not product of some error. The execution of an instruction that is intended for user programs and transfers control to the operating system. Such a request from the kernel is called a system call. Trap causes switching to OS code and to kernel mode. Once in kernel mode, a trap handler is executed to service the request. Restarted at the address following the address causing the trap. 36

37. System Call A mechanism used by an application program to request service from the operating system. Provide the interface between a process and the operating system itself. Popular system calls are open, read, write, close, wait, exec, fork, exit, and kill. Defines the programming environment. 37

38. An Example open (“/tmp/foo”); “open” lib function: store the system call number and the parameters in a predefined kernel memory location; trap(); (int #80 asm inst.) retrieve the response from a predefined kernel memory location; return the response to the calling application; User : Trap handler: transfer to gate: Gate routine: switch(sys_call_num) { case OPEN: … } store response in a predifined memory location; Return to user; Kernel : 38 Interrupt vector [80]

39. Check return values! #include … int status; status=open(“/tmp/foo”); if( status < 0 ) { perror( "Error opening file" ); / /equivalent to: //printf("Error opening file: %s\n",strerror(errno )); } 39

40. Error name Error code (number) Message ENOENT2 No such file or directory EINTR4 Interrupted system call EIO5I/O error EACCES13Permission denied EBUSY16 Device or resource busy Some Possible Values: 40

41. Working with System Calls 41

42. “man” Command 42 An interface to the online reference manuals Divided into categories, the first three are: (provided by "man man").  Executable programs or shell commands  System calls (functions provided by the kernel)  Library calls (functions within program libraries)

43. Example: “man mkdir” 43

44. Example: “man 2 mkdir” 44

45. Debugging System Calls 45

46. Debugging by Watching strace is a debugging utility to monitor the system calls Easy to use. Fast debugginng strace command Shows system calls, arguments, and return values -t to display when each call is executed -T to display the time spent in the call -e to limit the types of calls -o to redirect the output to a file -s limit the length of print strings. 46

47. Strace example: “strace ls /python/” open("/usr/share/locale/en_GB/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory) write(2, "ls: ", 4) = 4 write(2, "cannot access /python/", 22) = 22 open("/usr/share/locale/en_US/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/share/locale/en/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory) open("/usr/share/locale/en_GB/LC_MESSAGES/libc.mo", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=1474,...}) = 0 mmap(NULL, 1474, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f30b2df1000 close(3) = 0 write(2, ": No such file or directory", 27) = 27 write(2, "\n", 1) = 1 close(1) = 0 47

48. Strace example: “strace ls python/” stat("python/", {st_mode=S_IFDIR|0755, st_size=4096,...}) = 0 openat(AT_FDCWD, "python/", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3 fcntl(3, F_GETFD) = 0x1 (flags FD_CLOEXEC) getdents(3, /* 8 entries */, 32768) = 240 getdents(3, /* 0 entries */, 32768) = 0 close(3) = 0 fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 0),...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x79ac55f24000 write(1, "proj1 proj2 proj3 proj4 proj"..., 41) = 41 close(1) = 0 48

49. Strace example: “strace wc sample2.in” stat("sample2.in", {st_mode=S_IFREG|0777, st_size=490,...}) = 0 open("sample2.in", O_RDONLY) = 3 read(3, "\" The path of the righteous man "..., 16384) = 490 open("/usr/lib/x86_64-linux-gnu/gconv/gconv-modules.cache", O_RDONLY) = 4 fstat(4, {st_mode=S_IFREG|0644, st_size=26066,...}) = 0 mmap(NULL, 26066, PROT_READ, MAP_SHARED, 4, 0) = 0x7f81a4c88000 close(4) = 0 read(3, "", 16384) = 0 fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 4),...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f81a4c87000 write(1, " 1 96 490 sample2.in\n", 23) = 23 close(3) = 0 close(1) = 0 49

50. Using gdb 50 gdb (The GNU Debugger) is a debugger for Unix- like OSs. The code must be compiled by g++ using the -g flag. First, start the shell command gdb (“gdb programName”). The shell command gdb includes useful commands for debugging, such as exit, run, breaktrace, x (checking a value), break (adding a break point), conditional (for conditional break points), step/next in break points and more.

51. Loading a program The example is taken from cmu gdb tutorialcmu gdb tutorial They created a main file with two classes: Node and LinkedList. In the main, they create a LinkedList with 5 elements (1- 5), and then they remove them (one by one). Compiling: gcc main.c -g -o main Start gdb: gdb main 51

52. Running the program (gdb) run Starting program: main Program received signal SIGSEGV, Segmentation fault. Node ::next (this=0x0) at main.cc:28 28 Node * next () const { return _next; } (gdb) 52

53. Inspecting crashes (gdb) backtrace #0 Node ::next (this=0x0) at main.cc:28 #1 0x2a16c in LinkedList ::remove (this=0x40160, item_to_remove=@0xffbef014) at main.cc:77 #2 0x1ad10 in main (argc=1, argv=0xffbef0a4) at main.cc:111 (gdb) (gdb) x 0xffbef014 0xffbef014:0x00000001 (gdb) 53

54. Conditional breakpoints (gdb) break LinkedList ::remove Breakpoint 1 at 0x29fa0: file main.cc, line 52. (gdb) (gdb) condition 1 item_to_remove==1 (gdb) 54

55. Stepping (1) (gdb) run The program being debugged has been started already. Start it from the beginning? (y or n) y Breakpoint 1, LinkedList ::remove (this=0x40160, item_to_remove=@0xffbef014) at main.cc:52 52 Node *marker = head_; (gdb) step 53 Node *temp = 0; // temp points to one behind as we iterate (gdb) 55 while (marker != 0) { (gdb) 56 if (marker->value() == item_to_remove) { (gdb) Node ::value (this=0x401b0) at main.cc:30 30 const T& value () const { return value_; } (gdb) 55

56. Stepping (2) LinkedList ::remove (this=0x40160, item_to_remove=@0xffbef014) at main.cc:75 75 marker = 0; // reset the marker (gdb) 76 temp = marker; (gdb) 77 marker = marker->next(); (gdb) Node ::next (this=0x0) at main.cc:28 28 Node * next () const { return next_; } (gdb) Program received signal SIGSEGV, Segmentation fault. Node ::next (this=0x0) at main.cc:28 28 Node * next () const { return next_; } (gdb) 56

57. 57 Q & A EX1 Description