Memory Management – Process Loading and Linking

CS 350 – Spring 2003, 4/4/03+

Based on Stallings, Chapter 7

Purpose: This material to better understand problems which occur when memory management
involves swapping processes between memory and disk.

 Load Modules and address binding: A load module is a compiled and possibly linked (see
below) version of the source code. The processing of the source code is done with no
knowledge of where the resulting load module is put in memory. Thus the “process” when
loaded into memory, must ultimately have all addresses “mapped” into the “process address
space” in real memory before it can execute. This is called address binding.

Address binding can be done at:

Compile time
Load time
Execution (run) time

 Loading and linking

A program (load module) may be made up from a number of “object” module files.

To be executable in memory, a program must map all relative internal addresses (see below) in
the load module(s) to memory addresses (binding), and in addition any references made to other
modules must also be resolved (linking).

Thus to create an active process in memory, the modules must be both linked (resolve
references among modules) and loaded into memory.

 We distinguish between loading a single load module which requires only binding of he relative
addresses (already linked), and the loading of multiple modules which requires also linking (at
load or run time). The next three items assumes a single load module.

 Absolute loading
The references in the program load module are already resolved into specific physical memory
addresses.

- programmer must know where the process would be loaded in memory (or the strategy
for assigning processes to memory)

- modifications made to the process may require changing all addresses in the module
(recompile)

Chapter 9 Spring 2003 Memory management – Process Loading and Linking page 1
 - Absolute address assignment can be done either by the programmer or the
compiler/assembler. The latter means that the programmer uses symbolic references to
be later filled in by the compiler or assembler.

 Relocatable Loading ( bind to real addresses at load time)

Assume a single linked load module that can be located anywhere in memory.

It is not desirable to decide in advance into which region of memory s load module must be
loaded, so we now defer that decision to load time.

The module does not have absolute addresses, but addresses that are relative to some known
point, such as the start of the program module.

The loader places the module at location x, by adding x to each memory reference in the
module as it loads the module into memory. In order to do this the module needs a relocation
dictionary which tells where the addresses are, and how to translate them at load time.

If a process image is swapped out to disk, and then brought back into memory, it would have to
be loaded into the same location it was before (x), since it already has its memory references
resolved to absolute values because it was previously resolved at load time. The “process
image” swapped to disk generally retains the resolved absolute addresses in the memory
image that were created at initial load tine (Stallings p.. 329). Comment: re-setting the module
addresses to their pre-loaded relative (re-locatable) addresses would probably involve too much
overhead for swapping.

 Dynamic Run-time real address binding ( bind to real addresses at run time)
Assumes this is a single linked load module.
This would allow the swapping mechanism to restore a swapped process to an arbitrary
location in memory, not necessarily its old location … maximizes memory utilization.

Defer the calculation of absolute addresses until it is actually needed at run time.

Thus, the load module is loaded into main memory with all memory references in relative form
(unresolved to real) - for example the references would be offsets from the beginning of the
process.

It is not until an instruction is actually executed that the absolute address is calculated.

Because these actions are at run time, hardware assistance is needed for the dynamic address
translation in order to have good performance. The hardware adds a base address value to
each address in real time.

Chapter 9 Spring 2003 Memory management – Process Loading and Linking page 2
 Linking

The function of the linker is to take a collection of object modules and produce a load module.

Address references to other modules must be expressed symbolically in an unlinked object

module.

Linker may produce a single load module where all references are resolved relative to some
point in the module, if done before loading. If linking is deferred to later (loading or run time),
then the references to other modules (only) are left as symbolic with local references being
resolved to relative addresses.

 Linkage Editor

The nature of the address linkage depends on the type of load module to be created and when
the linkage occurs.

If (usual case), a relocatable load module is needed, then the link is done follows:

Each compiled object module is created with references relative to the beginning of the
beginning of the object module. All modules linked are put together in a single load module
with all references relative the origin of the load module.

A linker that produces a relocatable load module is often referred to as a linkage editor.

NOTE: distinguish between linking and logical to physical address binding

 Dynamic Linking

Meaning of “dynamic”: Defer linkage of external modules until after the load module has
been created: at load time or run time.

Load module contains unresolved references to other modules (symbolic) – these references can
be resolved either at load time or run time.

 Load-time dynamic linking:

Like relocatable loading above, except multiple modules are involved.

This is the “DLL” (Dynamic Link Library) concept in Windows or OS/2

The load module is read into main memory.

Chapter 9 Spring 2003 Memory management – Process Loading and Linking page 3
 Any reference to an external module causes the loader to find this module, load it, and alter the
reference to a relative address in memory from the beginning of the application.

Several advantages to this approach over static loading:

Easier to incorporate changes – no need to relink the entire application.

Automatic code sharing – OS will load a single copy of a routine for multiple applications
referencing it.

Easier for independent software developers to extend the function a widely used software
package such as an operating system- extension packages as a dynamic link module.

 Run-time Dynamic Linking (dynamic/run-time loading):

Like dynamic runtime address binding for a single load module above, except multiple
modules involved which must be loaded at run time when referenced.
This is the “DLL” (Dynamic Link Library) concept in Windows or OS/2

Some of the linking is postponed until execution time. External references to target modules
remain in the loaded module (in memory).

When a call is made to the absent module, the OS locates the module, loads it, and links it to the
calling module

 Comparison: dynamic address binding(single load module) vs dynamic linking (multiple

modules):

Dynamic address binding (single load module) allows an entire module to be moved around –
however, the structure of the module is static, being unchanged throughout the execution of the
process and from one execution to the next.

In some cases it is not possible to determine prior to execution which module will be required
thus dynamic linking will be required.

The advantage of dynamic linking is that it is not necessary to allocate memory for program
units unless those units are actually referenced.

Dynamic-Link Libraries (DLL‟s):

The following are some concepts on Dynamic-Link Libraries on the familiar DLL’s you see in
many Windows applications and in Windows system folders. They are taken from the book:
“Advanced Windows”, 3rd Ed., pp. 529-533, by Jeffrey Richter

Chapter 9 Spring 2003 Memory management – Process Loading and Linking page 4
A DLL is a set of modules, with each module containing a set of functions. These functions are
written with the expectation that an application (.exe file) or another DLL, will call them. The
source code files will be compiled and linked just as an exe file would be. The linker when
used in creating a DLL, results in a (DLL) file such that the Operating System loader will
recognize this file as a DLL rather than an exe file.

For an application or another DLL to call functions contained within a DLL, the DLL’s file
image must first be mapped into the calling processes addresses space. This can be
accomplished using one of two methods:

Implicit load-time linking

or
Explicit runtime linking
Once the DLL’s file image is mapped into the calling processes’s address space, the DLL’s
functions are available to all threads in the processes. After this mapping, the DLL code
becomes completely integrated into the process and the threads cannot distinguish the DLL
code and data from other code and data in the process address space.

Mapping a DLL into a Process „s Address Space

Implicit Linking (Load Time):

When the OS loads an exe file, the system examines the contents of the exe file image to see
which DLLs must be loaded for the application to run. The linker of the “base” exe file embeds
information in the exe modules which tells the loader which additional DLL’s must be linked at
load time. The loader/linker then links the specified DLL’s to the exe file during load time.

Explicit Linking (Run Time):

A DLL’s file image can be explicitly mapped into a process’s address space when one of the
processes threads calls a function in one of the DLL’s associated with the exe application. The
called DLL file images are then located, loaded, and mapped into the calling process’s address
space (dynamically at run time).

Chapter 9 Spring 2003 Memory management – Process Loading and Linking page 5