Loader and Linker

Three Working Items

Loading: loading an object program into memory for execution. Relocation: modify the object program so that it can be loaded at an address from the location originally specified. Linking: combines two or more separate object programs and supplies the information needed to allow references between them. A loader is a system program that performs the loading function. Many loaders also support relocation and linking. Some systems have a linker to perform the linking and a separate loader to handle relocation and loading.

Absolute Loader
An object program is loaded at the address specified on the START directive. No relocation or linking is needed Thus is very simple

No text record corresponds here. XXX indicates that the previous contents of these locations remain unchanged.

Absolute Loader Implementation

14 occupies two bytes if it is represented in char form.

When loaded into memory, 14 should occupy only one byte.

Bootstrap Loader
When a computer is first turned on or restarted, a special type of absolute loader must be executed (stored in ROM on a PC). The bootstrap loader loads the first program to be run by the computer usually the operating system, from the boot disk (e.g., a hard disk or a floppy disk) It then jumps to the just loaded program to execute it. Normally, the just loaded program is very small (e.g., a disk sectors size, 512 bytes) and is a loader itself. The just loaded loader will continue to load another larger loader and jump to it. This process repeats another the entire large operating system is loaded.

Bootstrap Loader Example

Convert 14 in char form to 14 in byte form

Bootstrap Loader Example

Convert 1 in char form to 1 in its ASCII code

Relocating Loader
Two methods to describe where in the object program to modify the address (add the program starting address)
Use modification records
Suitable for a small number of changes

Use relocation bit mask

Suitable for a large number of changes

Program Written in SIC/XE

PC-relative

Only these three lines need to be modified.

Base-relative

Base-relative

This program is written in SIC/XE instructions. Program counterrelative and base-relative addressing are extensively used to avoid the need for many address modification records.

The Object Program

Only lines 15, 35, and 65 need to be modified.

The Same Program Written in SIC

Direct addressing

Direct addressing

Direct addressing This program is written in SIC instructions. Only direct addressing can be used. As such, we need many modification records. This not only makes the object program bigger, it also slows down the loading process.

Relocation Bit Mask

If an object needs too many modification records, it would be more efficient to use a relocation bit mask to indicate where in the object program should be modified when the object program is loaded. A relocation bit is associated with each word of object code. Since all SIC instructions occupy one word, this means that there is one relocation bit for each possible instruction. If the relocation bit corresponding to a word of object code is set to 1, the programs starting address will be added to this word when the program is relocated.

Relocation Bit Mask Example

This one-byte F1 makes the LDX instruction on line 210 begins a new text record. This is because each relocation bit should be associated with a three-byte word. However, this data item occupies only one byte, which violates the Alignment rule.

Program Linking
A program may be composed of many control sections. These control sections may be assembled separately. These control sections may be loaded at different addresses in memory. External references to symbol defined in other control sections can only be resolved (calculating their addresses in memory) after these control sections are loaded into memory.

Program Linking Example

Object Program Example

Program Linking Example

Notice that program A defines LISTA and ENDA, program B defines LISTB and ENDB, and program defines LISTC and ENDC. Notice that the definitions of REF1, REF2, .., to REF7 in all of these three control sections are the same. Therefore, after these three control sections are loaded, no matter where they are loaded, the values of REF1 to REF7 in all of these programs should be the same.

REF1
Program A
LISTA is defined in its own program and its address is immediately available. Therefore, we can simply use program counter-relative addressing

Program B
Because LISTA is an external reference, its address is not available now. Therefore an extended-format instruction with address field set to 00000 is used. A modification record in inserted into the object code so that once LISTAs address is known, it can be added to this field.

Program C
The same as that processed in Program B.

REF2
Program A
Because LISTB is an external reference, its address is not available now. Therefore an extended-format instruction with address field set to 00004 is used. A modification record is inserted into the object code so that once LISTBs address is available, it can be added to this field.

Program B
LISTB is defined in its own program and its address is immediately available. Therefore, we can simply use program counter-relative addressing

Program C
The same as that processed in Program A.

REF3
Program A
The difference between ENDA and LISTA (14) is immediately available during assembly.

Program B
Because the values of ENDA and LISTA are unknown during assembly, we need to use an extended-format instruction with its address field set to 0. Two modification records are inserted to the object program one for +ENDA and the other for LISTA.

Program C
The same as that processed in Program B.

REF4
Program A
The difference between ENDA and LISTA can be known now. Only the value of LISTC is unknown. Therefore, an initial value of 000014 is stored with one modification record for LISTC.

Program B
Because none of ENDA, LISTA, and LISTCs values can be known now, an initial value of 000000 is stored with three modification records for all of them.

Program C
The value of LISTC is known now. However, the values for ENDA and LISTA are unknown. An initial value of 000030 is stored with two modification records for ENDA and LISTA.

After Loading into Memory

Suppose that program A is loaded at 004000, program B at 004063, and program C at 0040E2. Notice that REF4, REF5, REF6, and REF7 in all of these three programs have the same values.

REF4 after Linking

Program A
The address of REF4 is 4054 (4000 + 54) because program A is loaded at 4000 and the relative address of REF4 within program A is 54. The value of REF4 is 004126 because
The address of LISTC is 0040E2 (the loaded address of program C) + 000030 (the relative address of LISTC in program C) 0040E2 + 000014 (constant already calculated) = 004126.

REF4 after Linking

Program B
The address of REF4 is 40D3 (4063 + 70) because program B is loaded at 4063 and the relative address of REF4 within program A is 70. The value of REF4 is 004126 because
The address of LISTC is 004112 The address of ENDA is 004054 The address of LISTA is 004040 004054 + 004112 004040 = 004126

Instruction Operands
For references that are instruction operands, the calculated values after loading do no always appear to be equal. This is because there is an additional address calculation step involved for program-counter (base) relative instructions. In such cases, it is the target addresses that are the same. For example, in program A, the reference REF1 is a program-counter relative instruction with displacement 1D. When this instruction is executed, the PC contains the value 4023. Therefore the resulting address is 4040. In program B, because direct addressing is used, 4040 (4000 + 40) is stored in the loaded program for REF1.

The Implementation of a Linking Loader

A linking loader makes two passes over its input
In pass 1: assign addresses to external references In pass 2: perform the actually loading, relocation, and linking

Very similar to what a two-pass assembler does.

Data Structures
External symbol tables (ESTAB)
Like SYMTAB, store the name and address of each external symbol in the set of control sections being loaded. It needs to indicate in which control section the symbol is defined.

PROGADDR
The beginning address in memory where the linked program is to be loaded. (given by the OS)

CSADDR
It contains the starting address assigned to the control section currently being scanned by the loader. This value is added to all relative addresses within the control sections.

Algorithm
During pass 1, the loader is concerned only with HEADER and DEFINE record types in the control sections to build ESTAB. PROGADDR is obtained from OS. This becomes the starting address (CSADDR) for the first control section. The control section name from the header record is entered into ESTAB, with value given by CSADDR.

Algorithm (Contd)
All external symbols appearing in the DEFINE records for the current control section are also entered into ESTAB. Their addresses are obtained by adding the value (offset) specified in the DEFINE to CSADDR. At the end, ESTAB contains all external symbols defined in the set of control sections together with the addresses assigned to each. A Load Map can be generated to show these symbols and their addresses.

A Load Map

Algorithm (Contd)
During pass 2, the loader performs the actual loading, relocation, and linking. CSADDR is used in the same way as it was used in pass 1
It always contains the actual starting address of the control section being loaded.

As each text record is read, the object code is moved to the specified address (plus CSADDR) When a modification record is encountered, the symbol whose value is to be used for modification is looked up in ESTAB. This value is then added to or subtracted from the indicated location in memory.

Reference Number
The linking loader algorithm can be made more efficient if we assign a reference number to each external symbol referred to in a control section. This reference number is used (instead of the symbol name) in modification record. This simple technique avoid multiple searches of ESTAB for the same symbol during the loading of a control section.
After the first search for a symbol (the REFER records), we put the found entries into an array. Later in the same control section, we can just use the reference number as an index into the array to quickly fetch a symbols value.

Reference Number Example

Reference number 01 is reserved for the current control section name. All other reference numbers start from 02.

Machine Independent Features

Automatic Library Search

Many linking loaders can automatically incorporate routines from a subprogram library into the program being loaded. (E.g., the standard C library) The subroutines called by the program are automatically fetched from the library, linked with the main program, and loaded. The programmer does not need to take any action beyond mentioning the subroutine names as external references in the source program

Automatic Library Search

Linking loader that support automatic library search must keep track of external symbols that are referred to, but not defined, in the primary input to the loader. At the end of pass 1, the symbols in ESTAB that remain undefined represent unresolved external references. The loader searches the library for routines that contain the definitions of these symbols, and processes the subroutines found by this search process exactly as if they had been part of the primary input stream.

Automatic Library Search

The subroutines fetched from a library in this way may themselves contain external references. It is necessary to repeat the library search process until all references are resolved. If unresolved references remain after the library search is completed, they are treated as errors. If a symbol (or a subroutine name) is defined both in the source program and in the library, the one in the source program is used first. A programmer can make his own library easily on UNIX by using the ar command.

Loader Options
Many loaders allow the user to specify options that modify the standard processing. For example:
Include program-name (library name)
Direct the loader to read the designated object program from a library

Delete csect-name
Instruct the loader to delete the named control sections from the set of programs being loaded

Change name1, name2

Cause the external symbol name1 to be changed to name2 wherever it appears in the program

Loader Options Application

In the COPY program, we write two subroutines RDREC and WRREC to perform read records and write records. Suppose that the computer system provides READ and WRITE subroutines which has similar but advanced functions. Without modifying the source program and reassembling it, we can use the following loader options to make the COPY object program use READ rather than RDREC and WRITE rather than WRREC.
Include READ (Util) Include WRITE (Util) Delete RDREC, WRREC Change RDREC, READ Change WRREC, WRITE

Loader Design Options

Linkage Editor
The difference between a linkage editor and a linking loader:
A linking loader performs all linking and relocation operations, including automatic library search, and loads the linked program into memory for execution. A linkage editor produces a linked version of the program, which is normally written to a file for later execution.

Linkage Editor
When the user is ready to run the linked program, a simple relocating loader can be used to load the program into memory. The only object code modification necessary is the addition of an actual address to relative values within the program. The linkage editor performs relocation of all control sections relative to the start of the linked program.

Linkage Editor
All items that need to be modified at load time have values that are relative to the start of the linked program. This means that the loading can be accomplished in one pass with no external symbol table required. Thus, if a program is to be executed many times without being reassembled, the use of a linkage editor can substantially reduces the overhead required.
Resolution of external references and library searching are only performed once.

Dynamic Linking
Linkage editors perform linking before the program is loaded for execution. Linking loaders perform these same operations at load time. Dynamic linking postpones the linking function until execution time.
A subroutine is loaded and linked to the test of the program when it is first called.

Dynamic Linking Application

Dynamic linking is often used to allow several executing programs to share one copy of a subroutine or library. For example, a single copy of the standard C library can be loaded into memory. All C programs currently in execution can be linked to this one copy, instead of linking a separate copy into each object program.

Dynamic Linking Application

In an object-oriented system, dynamic linking is often used for references to software object. This allows the implementation of the object and its method to be determined at the time the program is run. (e.g., C++) The implementation can be changed at any time, without affecting the program that makes use of the object.

Dynamic Linking Advantage

The subroutines that diagnose errors may never need to be called at all. However, without using dynamic linking, these subroutines must be loaded and linked every time the program is run. Using dynamic linking can save both space for storing the object program on disk and in memory, and time for loading the bigger object program.

On PC Windows or UNIX operating systems, normally you are using (e.g., ld) a linkage editor to generate an executable program.

Dynamic Linking Implementation

A subroutine that is to be dynamically loaded must be called via an operating system service request.
This method can also be thought of as a request to a part of the loader that is kept in memory during execution of the program

Instead of executing a JSUB instruction to an external symbol, the program makes a load-and-call service request to the OS. The parameter of this request is the symbolic name of the routine to be called..

Dynamic Linking Implementation

The OS examines its internal tables to determines whether the subroutine is already loaded. If needed, the subroutine is loaded from the library. Then control is passed from the OS to the subroutine being called. When the called subroutine completes its processing, it returns to its caller (operating system). The OS then returns control to the program that issues the request. After the subroutine is completed, the memory that was allocated to it may be released.

Dynamic Linking Implementation

However, often this is not done immediately. If the subroutine is retained in memory, it can be used by later calls to the same subroutine without loading the same subroutine multiple times. Control can simply pass from the dynamic loader to the called routine directly.

Implementation Example

Issue a load-and-call service request

Load the called subroutine into memory

Control is passed to the loaded subroutine.

Control is returned The called subroutine to the loader and this time is already loaded. later returned to the user program