Processes, Execution, and State What is a Process? 3A. What is a - PDF document

4/8/2017 Processes, Execution, and State What is a Process? 3A. What is a Process? • an executing instance of a program 3B. Process Address Space – how is this different from a program? 3Y. Libraries • a virtual private computer 3C. Process Operations – what does a virtual computer look like? 3D. Implementing Processes – how is a process different from a virtual machine? 3E. Asynchronous Exceptions • a process is an object 3U. User-mode Exceptions – characterized by its properties (state) 3X. Object modules and Load modules – characterized by its operations 3Z. Linkage conventions Processes, Execution and State 1 Processes, Execution and State 2 What is “state”? Program vs Process Address Space • the primary dictionary definition of “state” is ELF header section 1 header section 2 header section 3 header target ISA type : code – “a mode or condition of being” type : data type : sym # load sections load adr: 0xxx load adr: 0xxx length : ### # info sections length : ### length : ### – an object may have a wide range of possible states initialized symbol compiled • all persistent objects have “state” data code table values – distinguishing it from other objects – characterizing object's current condition 0x00000000 0x0100000 0x0110000 • contents of state depends on object shared code private data shared lib1 shared lib2 – complex operations often mean complex state – we can save/restore the aggregate/total state shared lib3 private stack 0x0120000 0xFFFFFFFF – we can talk of a subset (e.g. scheduling state) Processes, Execution and State 3 Processes, Execution and State 4 Address Space: Code Segments Address Space: Data Segments • load module (output of linkage editor) • data too must be initialized in address space – all external references have been resolved – process data segment must be created – all modules combined into a few segments – initial contents must be copied from load module – includes multiple segments (text, data, BSS) – BSS: segments to be initialized to all zeroes • code must be loaded into memory – map segment into virtual address space – a virtual code segment must be created • data segments – code must be read in from the load module – are read/write, and process private – map segment into virtual address space – program can grow or shrink it (with sbrk syscall) • code segments are read/only and sharable – many processes can use the same code segments Processes, Execution and State 5 Processes, Execution and State 6 1

4/8/2017 Address Space: Stack Segment Characteristics of Libraries • size of stack depends on program activities • Many advantages – grows larger as calls nest more deeply – Reusable code makes programming easier – amount of local storage allocated by each procedure – Asingle well written/maintained copy – after calls return, their stack frames can be recycled – Encapsulates complexity … better building blocks • OS manages the process's stack segment • Multiple bind-time options – stack segment created at same time as data segment – Static … include in load module at link time – some allocate fixed sized stack at program load time – Shared … map into address space at exec time – some dynamically extend stack as program needs it – Dynamic … choose and load at run-time • Stack segments are read/write and process private • It is only code … it has no special privileges Processes, Execution and State 7 Processes, Execution and State 8 Sharable executables address space – shared executable • code segments are usually read-only – one copy could be shared by multiple processes – allow more process to run in less memory shared code private data private stack • code has been relocated to specific addresses – all procs must use shared code at the same address 0x00000000 0xFFFFFFFF • only the code segments are sharable – each process requires its own copy of writable data – data must be loaded into each process at start time Processes, Execution and State 9 Processes, Execution and State 10 Shared Libraries Advantages of Shared Libraries • reduced memory consumption • library modules are usually added to load module – one copy can be shared by multiple – each load module has its own copy of each library processes/programs • this dramatically increases the size of each process • faster program start-ups – program must be re-linked to incorporate new library – if it is already in memory, it need not be loaded again • existing load modules don't benefit from bug fixes • simplified updates • make each library a sharable code segment – library modules are not included program load – one in memory copy, shared by all processes modules – keep the library separate from the load modules – library can be updated (e.g. new version w/ bug fixes) – operating system loads library along with program – programs automatically get new version when restarted Processes, Execution and State 11 Processes, Execution and State 12 2

4/8/2017 Implementing Shared Libraries address space – shared libraries • multiple code segments in a single address space – one for the main program, one for each shared library 0x00000000 0x0100000 0x0110000 – each sharable, and mapped in at a well-known shared code private data shared lib1 shared lib2 address • deferred binding of references to shared libs shared lib3 private stack – applications are linkage edited against a stub library 0x0120000 • stub module has addresses for each entry point, but no code 0xFFFFFFFF • linkage editor resolves all refs to standard map-in locations – loader must find a copy of each referenced library • and map it in at the address where it is expected to be Processes, Execution and State 13 Processes, Execution and State 14 Indirect binding to shared libraries Stub modules vs real shared libraries stub module: libfoo.a The real shared object is mapped symbol table: into the process’ address space at that fixed address. It begins with a 0: libfoo.so, shared library redirection table D 1 jump table, that effectively seems to jump foo 1: foosub1, global, absolute, 0x1020000 give each entry point a fixed address. 2: foosub2, global, absolute, 0x1020008 shared library: libfoo.so … … 3: foosub3, global, absolute, 0x1020010 (to be mapped in at 0x1020000) call foo 4: foosub4, global, absolute, 0x1020018 … foo: … 0x1020000 jmp foosub1 … ... Program is linkage edited against the 0x1020008 jmp foosub2 stub module, and so believes each of 0x1020010 jmp foosub3 code segment the contained routines to be at a fixed (read only) shared library address. 0x1020018 jmp foosub4 (read only, at well known …. location) foosub1: … Processes, Execution and State foosub2: … 15 Processes, Execution and State 16 Loading and Binding w/DLLs Limitations of Shared Libraries code segment new code • not all modules will work in a shared library (read only) segment – they cannot define/include static data storage foo: … • they are read into program memory ... … – whether they are actually needed or not call foo … • called routines must be known at compile-time Procedure Linkage Table (writeable) – only the fetching of the code is delayed 'til run-time – symbols known at compile time, bound at link time run time jump foo load foo.dll loader • Dynamically Loadable Libraries are more general – they eliminate all of these limitations ... at a price Processes, Execution and State 17 Processes, Execution and State 18 3