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

4/8/2018 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? • a virtual private computer 3Y. Static and shared libraries – what does a virtual computer look like? 3C. Process operations – how is a process different from a virtual machine? 3D. Implementing processes • a process is an object 3E. Asynchronous Exceptions – characterized by its properties (state) 3U. User-mode exception handling – characterized by its operations 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/2018 (Address Space: Stack Segment) (Address Space: Shared Libraries) • size of stack depends on program activities • static libraries are added to load module – grows larger as calls nest more deeply – each load module has its own copy of each library – amount of local storage allocated by each procedure – program must be re-linked to get new version – after calls return, their stack frames can be recycled • make each library a sharable code segment • OS manages the process's stack segment – one in-memory copy, shared by all processes – stack segment created at same time as data segment – keep the library separate from the load modules – some allocate fixed sized stack at program load time – some dynamically extend stack as program needs it – operating system loads library along with program • Stack segments are read/write and process private • reduced memory use, faster program loads • easier and better library upgrades Processes, Execution, and State 7 Processes, Execution, and State 8 Characteristics of Libraries Shared Libraries • Many advantages • library modules are usually added to load module – Reusable code makes programming easier – each load module has its own copy of each library – Asingle well written/maintained copy • this dramatically increases the size of each process – program must be re-linked to incorporate new library – Encapsulates complexity … better building blocks • existing load modules don't benefit from bug fixes • Multiple bind-time options • make each library a sharable code segment – Static … include in load module at link time – one in physical memory copy, shared by all processes – Shared … map into address space at exec time – keep the library separate from the load modules – Dynamic … choose and load at run-time – operating system loads library along with program • It is only code … it has no special privileges Advantages of Shared Libraries Implementing Shared Libraries • reduced memory consumption • multiple code segments in a single address space – one copy shared by multiple processes/programs – one for the main program, one for each shared library • faster program start-ups – each sharable, mapped in at a well-known address • deferred binding of references to shared libs – if it is already in memory, it need not be loaded again • simplified updates – applications are linkage edited against a stub library • stub module has addresses for each entry point, but no code – library modules not included program load modules • linkage editor resolves all refs to standard map-in locations – library can be updated (e.g. new version w/ bug fixes) – loader must find a copy of each referenced library – programs automatically get new version on restart • and map it in at the address where it is expected to be 2

4/8/2018 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: … foosub2: … 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 (run-time binding to DLLs) Shared Libraries vs. DLLs • load module includes a Procedure Linkage Table • both allow code sharing and run-time binding – addresses for routines in DLL resolve to entries in PLT • shared libraries – each PLT entry contains a system call to run-time – do not require a special linkage editor loader (asking it to load the corresponding routine) – shared objects obtained at program load time • first time a routine is called, we call run-time • Dynamically Loadable Libraries loader – require smarter linkage editor, run-time loader – which finds, loads, and initializes the desired routine E 1 – modules are not loaded until they are needed – changes the PLT entry to be a jump to loaded routine • automatically when needed, or manually by program – then jumps to the newly loaded routine – complex, per-routine, initialization can be performed • subsequent calls through that PLT entry go • e.g. allocation of private data area for persistent local directly variables 3