© Janice Regan, CMPT 300, May CMPT 300 Introduction to Operating Systems Memory: Relocation

© Janice Regan, CMPT 300, May Shared files  A file may be shared by more than one directory (or user)  Two approaches to sharing  Hard link Once linked file is always available Entry for file added to directory file to link  Symbolic link A file containing the pathname to the file to be linked Treated like any other file in the directory If file linked to is deleted, link can no longer access the file

© Janice Regan, CMPT 300, May File types: Unix  Now have discussed  Regular files (used for user information) Binary Ascii Contain data, user code, compiled code, executables  Directory files  Symbolic links  Also have  special files: contain no data, provide a way to map devices to file names

© Janice Regan, CMPT 300, May Using regular files  When developing an application a user will use a computer language  Compile, link, execute  The compiler will save a file to the disk that has a special type, such a file is called an object module.  An object module includes machine executable instructions  Executable file is loaded (by the loader) to put it in memory when it is made into a process C codecompilerAssembler codeassembler Machine language Object file linker Machine language Executable file

© Janice Regan, CMPT 300, May Machine instructions  Remember that machine instructions, like those in the executable include the addresses of variables stored in the memory image and other instructions stored in the command portion of the memory image  When we load the executable into memory to run it those addresses must remain valid.  Simplest solution is to always load the executable at the same location (absolute loading)  Not practical with multiprocessing  Need to use offsets to accomplish relocatable loading

© Janice Regan, CMPT 300, May Absolute loading  Addresses used in machine code all assume that the executable will be loaded at location x in the memory  All machine instructions that use absolute addresses are assigned those addresses  at compile/assembly time by the compiler or assembler OR  During program development by the programmer Problem: must know in advance where the executable will be placed Reasonable only when programming a special process CPU for a particular purpose (for example an embedded CPU for controlling and operating an electronic device)

© Janice Regan, CMPT 300, May Absolute loading: Limitations  Useful only  Without multiprocessing (one program at a time)  Or with a small number of fixed partitions, must specifiy at compile time which partition is to be used  Even then  Memory space is wasted when process does not fill partition  Processes, once compiled can run in only one partition (constrained by addressing) OS Location x Location 0 Program Starts at location x x: beginning of first fixed partition Program Starts at location y y: beginning of second fixed partition Location y

© Janice Regan, CMPT 300, May Fixed partitions, varying sizes Operating system P1 P2 P3 p4

© Janice Regan, CMPT 300, May Multiprocessing: fixed partitions  Partitions of equal size  Any program whose image size is <= to the partition size can be loaded into any available partition  Internal fragmentation will occur since not all processes will fill their partitions  Some processes may be too larger for the partition size: requires overlays, programmer breaks program into units that can fit in one partition and alternates them in his partition Operating system P1 P2 P3 P4 p5

© Janice Regan, CMPT 300, May Fixed partitions varying size: 1 FIFO Operating system P1 P2 P3 p4

© Janice Regan, CMPT 300, May Absolute loading: other difficulties  When using libraries or other previously compiled routines must  Separately compile and link every combination of routines so that the object contains all the routines and their relative addresses in the compiled and linked code  Or must know the sizes of each routine to be combined, be sure no labels are used in multiple routines and have a complicated support method to assure that addressing is done correctly in the assembled code

© Janice Regan, CMPT 300, May Relocatable loading: contiguous process image  All processes are compiled/assembled with the assumption that they will be loaded at location 0 in memory  When a process runs then  determine where in memory its image will fit  Finds the address where the first bit of the object file will be placed (address x)  Adds x to every address referred to in the compiled/assembled code.  The relocation can be done at different times

© Janice Regan, CMPT 300, May Relocation  At compile time  Must know offset at compile time  Must recompile if offset changes  Not generally practical

© Janice Regan, CMPT 300, May Static Relocation  At load time: Static relocation  At compile time append a relocation table to the end of the executable  The relocation table contains a list of all addresses that need to be relocated (all absolute addresses)  At load time determine were the executable will be loaded into memory and add the appropriate offset to each variable or other absolute address (e.g. branch destination) in the relocation table  Relocation calculation done at load time  Cannot move the process to another location during execution.  External references (to other modules) are resolved at load time

© Janice Regan, CMPT 300, May Static Relocation: problem  The relocation table is used before the program begins execution  All absolute addresses are relocated  The process begins to run  As the process runs relative addresses (and pointers) may be calculated and stored in variables  The process is swapped out of memory  When the process is moved back into memory  The loader can recalculate all the absolute addresses from the relocation table and move the code to a new location  However all stored addresses refer to the location in memory where the code was originally loaded so when a stored address is used it will point to the wrong place (can even be outside of the process image at the new location)

© Janice Regan, CMPT 300, May Static relocation: limitations  As shown in the previous example static relocation will not allow the image of the process to be moved from its originally allocated position.  Requiring a process to always be loaded at the same place significantly decreases the efficiency of time sharing algorithms  Before the process can be reloaded all processes using any part of the memory space previously allocated to the process must be removed from physical memory.

© Janice Regan, CMPT 300, May Dynamic Relocation  At compile time relative addresses are retained in the loaded executable  Special hardware for fast address translation (MMU) memory management unit  Process ‘thinks’ it is executing at memory location 0, (the logical address) MMU translates to actual location (the physical address)  When an instruction is executed any necessary absolute addresses are calculated

© Janice Regan, CMPT 300, May Dynamic Relocation: Hardware program data stack Process contol Base register bound register Adder Relative address offset Absolute physical address Comparator Error: out of bound: interrupt MMU

© Janice Regan, CMPT 300, May Linking: External References  An application may use libraries, or may be distributed across multiple files.  The linker/loader  Takes as input a collection of object modules  In each object module there may be address references to other modules  Absolute loading  programmer or compiler specified physical addresses  Relocatable linking/loading  The linker/loader combines the modules into a single load module with consistent addresses relative to a common point (usually 0).  This module can be loaded at any location in memory  Dynamic or run-time linking  Allows swapping and relocation of the load module within memory

© Janice Regan, CMPT 300, May External References  An application may use libraries, or may be distributed across multiple files.  The linker  Takes as input a collection of object modules  In each object module there may be address references to other modules  Relocatable linking (using a linkage editor at compile time and a loader capable of static relocation)  Each module assumes it starts at address 0 (beginning of the load module)  Linker makes executable where each object module has addresses relative to the start of the same load module (see next slide)

© Janice Regan, CMPT 300, May Relocatable linking: example Data module 1 Code module 1 Data module 2 Code module 2 Library code Library Data Separate compiled and assembled object modules Load module Data module 1 Code module 1 0 Logical address 0 Three separately compiled object codes. Each starts at logical address zero. All addresses internal to each object modules are relative to address 0 at the beginning of that module. Data module 2 Code module 2 Library code Library Data Logical address 0 Logical address x Logical address y One linked load module, All addresses in module 1 addressing module 2 or library must be changed to point to the new logical addresses in the load module. All addresses internal to module 2 must be changed to be relative to x, in the library to be relative to y. External references from module 2 or the library must also be updated to be consistent within the load module

© Janice Regan, CMPT 300, May Relocatable Linking/Loading  When a load module is statically linked it will contain internally consistent logical addresses and can be loaded as one unit.  Each combination of modules and libraries needed must be separately linked to produce separate load modules  Sharing of libraries/modules is not possible. Each load module includes its own copy of the library or module

© Janice Regan, CMPT 300, May Dynamic load time linking  Defer linking with external modules until load time  While the load module is loading any reference in it to an external module (target module) causes  The target module’s load module to be loaded into to image  The target module can be dynamically loaded starting after the initial load module. References in the load module to addresses in the target module can be updated  Prevents need for relinking when a component is upgraded (commercial software may only supply the executable, cannot be relinked only reloaded)  Provides basis for code sharing (OS loads one copy of modules being used by multiple processes)  Provides a mechanism to easily extend the functionality of a system by adding dynamic link modules

© Janice Regan, CMPT 300, May Run-time Dynamic linking  Linking does not occur until the reference is encountered during execution  Allows modules that are used only in some paths through the application to be loaded only when needed