Lecture 3 – Processes

1. Lecture 3 – Processes • Overview of Von Neumann • Compiled vs. Interpreted • Programs • Compiling • Linking • Processes • Invoking • States • Resources • I/O Redirection • Signals

2. Overview of Von Neumann Model • CPU • Central Processing Unit • “Brains” of the computer • Consists of processing unit & control unit • Reads instructions and executes them

3. Opcodes • N-bit instruction • Some portion is operation • ADD, AND, OR, NOT, JMP, etc • Remainder is options for opcode • Specify registers, memory addresses, etc

4. CPU Instruction Cycle • Fetch Instruction • Decode Instruction • Evaluate Address of Operands (if needed) • Fetch Operands (if needed) • Execute • Store Results

5. Building A Program • Steal Source Code • ??? • Profit

6. Building A Program • Source Code • Object File • “Executable” / “Binary”

7. Source Code • Easy for humans to read • Hard for computer • Must conform to language’s particular syntax rules • Usually spread across multiple files

8. Source Code • In order to make it computer-friendly, we must “compile” it: • Verifies syntax is correct, then… • …creates object file.

9. Object File • Consists of 2 parts • Table of contents (symbols) • Actual code • Only contains code that came from original source file

10. Object Files • We still don’t have a program • Object code is nice, but not quite usable yet • We must now “link” our object files into a single executable

11. Object Files • Assume we have multiple object files • This is very common • Some files will need symbols from other files • Symbols include: • Variable names • Functions

12. Object Files • We have 2 lists: • Symbols defined in this file • Symbols required by this file • When we build a program, we do a 2-pass approach • Pass 1: Populate above lists • Pass 2: Locate necessary symbols

13. Object Files • Pass 2 • For every required symbol, we go through all files’ “defined symbols” list. • If we find symbol, we’re all good • If we fail to find all required symbols, we can’t build program

14. Programs • Assuming linking went okay, we now have a program • It’s static (content doesn’t get modified) • Content is rigidly formatted • Linux: ELF and others • Windows: EXE and (deprecated) COM

15. Miscellaneous • Libraries • IDEs • User vs. kernel mode

16. Libraries • We know we like them • What are they?

17. Libraries • We know we like them • What are they? • “common object files” • Still have TOC & code • Linux: .so • Windows: .dll*

18. Libraries • Very common collection of functions

19. Libraries • Very common collection of functions • Why rewrite them?

20. Libraries • Very common collection of functions • Why rewrite them? • Programmers are stupid and make mistakes • Different interfaces • Different internal behavior

21. Libraries • Very common collection of functions • Why rewrite them? • Programmers are stupid and make mistakes • Different interfaces • Different internal behavior • ….so let’s leave them alone

22. IDEs • Invoking tools individually is hard • GUIs are nice • Let’s put all the tools together

23. User vs. Kernel Mode • User mode • “Unprivileged”, “standard”, etc • Basic access to stuff • Kernel Mode • “Privileged”, etc • Used for system calls • Dangerous to play in this mode • NOTE: These are hardwarepermissions

24. Processes • Well, we finally got to it! • Process is a running program • Could be active, dormant, zombie, etc

25. Programs • Two parts • Text • Data • Initialized Read-Only • Initialized Read/Write • Uninitialized • This “data” is global • Not stuff on stack • “Local data” is inside functions

26. Text • Machine instructions (binary) • Typically read-only

27. Text • Machine instructions (binary) • Typically read-only • No self-modifiable code • Allows multiple instances of same code to run simultaneously

28. Data • Initialized Read-Only • Initialized Read/Write • Uninitialized

29. Initialized Read-Only • Process sets the value • Will never change during the course of execution • const inti = 5;

30. Initialized Read-Write • Process sets the value • Can change as needed • inti = 13;

31. Uninitialized • Block Started Symbol (BSS) • Very modifiable • char *myString;

32. Utility Programs • file (L) • Heuristically determine the type of the file specified • Size (L) • Display size of text, bss, and data

33. Utility Programs • ldd (L); tasklist /m (W) • Shows required libraries to run programs • env (L); set (W) • Display the environment • install (L) • Install a program

34. Utility Programs • nm (L) • Display symbol names in program or object file • strip (L) • Strip symbol names in program or object file

35. Utility Programs • nm (L) • Display symbol names in program or object file • strip (L) • Strip symbol names in program or object file • Why would we want to do this?

36. Invoking a Process • Program sits idle on HDD • CLI or GUI will invoke program • Exec system call • OS “loads” program into RAM • Creates req. data structures • This resulting entity is a process

37. Loading • Static Loading • Dynamic Loading

38. Static Loading Load…

39. Static Loading Load… everything…

40. Static Loading Load… everything… at one time…

41. Static Loading Load… everything… at one time… at process initiation

42. Dynamic Loading Load…

43. Dynamic Loading Load… core program…

44. Dynamic Loading Load… core program… at process initialization.

45. Dynamic Loading Load… core program… at process initialization. What’s missing?

46. Dynamic Loading Load… core program… at process initialization. Load…

47. Dynamic Loading Load… core program… at process initialization. Load… other libraries…

48. Dynamic Loading Load… core program… at process initialization. Load… other libraries… on demand.

49. Starting a Process • A program invokes the process • The “invoker” calls the process’s main() function • intargc • char **argv • char **envp

50. Environmental Variables • “System” variables • By convention • ALL_CAPITAL • By syntax rules • ALL_ONE_WORD