Chapter 3

Loaders and Linkers

1
Introduction

•To execute an object program, we need

•Relocation, which modifies the object program so that it can be
loaded at an address different from the location originally
specified
•Loading and Allocation, which allocates memory location and
brings the object program into memory for execution (Section
2.2.2)
•Linking, which combines two or more separate object programs
and supplies the information needed to allow references between
them (Section 2.3.5)

2
Overview of Chapter 3

•Type of loaders
•assemble-and-go loader
•absolute loader (bootstrap loader)
•relocating loader (relative loader)
•direct linking loader
•Design options
•linkage editors
•dynamic linking
•bootstrap loaders

3
Assemble-and-go Loader

•Characteristic
•the object code is stored in memory after assembly
•single JUMP instruction
•Advantage
•simple, developing environment
•Disadvantage
•whenever the assembly program is to be executed, it has to be
assembled again
•programs have to be coded in the same language

4
3.1 Basic Loader Functions

•Section 3.1.1 discusses the functions and design of an

absolute loader and the loader algorithm.
•Section 3.1.2 presents an example of a very simple
absolute loader for SIC/XE.
3.1.1 Design of an Absolute Loader

•Absolute Loader
•Advantage
• Simple and efficient
•Disadvantage
• The need for programmer to specify the actual address
• difficult to use subroutine libraries
•Program Logic
•Next slice

6
 (a) Object program
Figure 3.1 Loading an absolute program
 Memory
address Contents

(b) Program loaded in memory

Figure 3.1 Loading an absolute program

Fig. 3.2 Algorithm for an absolute loader

Figure 3.2 Algorithm for an absolute loader

9
Object Code Representation

•Figure 3.1 (a)

•each byte of assembled code is given using its hexadecimal
representation in character form
•easy to read by human beings
•In general
•each byte of object code is stored as a single byte
•most machine store object programs in a binary form
•we must be sure that our file and device conventions do not cause
some of the program bytes to be interpreted as control characters

10
3.1.2 A Simple Bootstrap Loader

•Bootstrap Loader
•When a computer is first tuned on or restarted, a special type of
absolute loader, called bootstrap loader is executed
•This bootstrap loads the first program to be run by the computer -
- usually an operating system
•Example (SIC bootstrap loader)
•The bootstrap itself begins at address 0
•It loads the OS starting address 0x80
•No header record or control information, the object code is
consecutive bytes of memory

11
Figure 3.3 Bootstrap loader for SIC/XE
Fig. 3.3 SIC Bootstrap Loader Logic

Begin
X=0x80 (the address of the next memory location to be loaded
Loop
A←GETC (and convert it from the ASCII character code to the value
of the hexadecimal digit)
save the value in the high-order 4 bits of S
A←GETC
combine the value to form one byte A← (A+S)
store the value (in A) to the address in register X
X←X+1
End GETC A ← read one character
if A = 0x04 then jump to 0x80
if A < 48 then GETC
A ← A-48 (0x30)
if A < 10 then return
0~9: 4810 ~ 5710(0x30 ~ 0x39)
A ← A-7 (58+7=65)
A~F: 6510 ~ 7010(0x41 ~ 0x46)
return

13
3.2 Machine-Dependent Loader Feature

•3.2.1 Relocation
•3.2.2 Program Linking
•3.2.3 Algorithm and Data Structures for a Linking Loader
3.2.1 Relocating Loaders

•Motivation
•efficient sharing of the machine with larger memory and when
several independent programs are to be run together
•support the use of subroutine libraries efficiently
•Two methods for specifying relocation
•modification record (Fig. 3.4, 3.5)
•relocation bit (Fig. 3.6, 3.7)
• each instruction is associated with one relocation bit
• these relocation bits in a Text record is gathered into bit masks

15
 Line Loc Source statement Object code

Figure 3.4 Example of a SIC/XE program (from Fig. 2.6).

Figure 3.5 Object program with relocation by Modification records.
Modification Record

•For complex machines

•Also called RLD specification
•Relocation and Linkage Directory
Modification record
col 1: M
col 2-7: relocation address
col 8-9: length (halfbyte)
col 10: flag (+/-)
col 11-17: segment name

18
 Line Loc Source statement Object code

Figure 3.6 Relocatable program for a standard SIC machine.

Figure 3.7 Object program with relocation by bit mark.
Relocation Bit

•For simple machines

•Relocation bit Text record
col 1: T
•0: no modification is necessary col 2-7: starting address
col 8-9: length (byte)
•1: modification is needed col 10-12: relocation bits
col 13-72: object code

•Twelve-bit mask is used in each Text record

•since each text record contains less than 12 words
•unused words are set to 0
•any value that is to be modified during relocation must coincide
with one of these 3-byte segments
• e.g. line 210

21
Program Linking

•Goal
•Resolve the problems with EXTREF and EXTDEF from different
control sections
•Linking
•1. User, 2. Assembler, 3. Linking loader
•Example
•Program in Fig. 3.8 and object code in Fig. 3.9
•Use modification records for both relocation and linking
• address constant
• external reference

22
 Loc Source statement Object code

Figure 3.8 Sample programs illustrating linking and relocation.

 Loc Source statement Object code

Figure 3.8 Sample programs illustrating linking and relocation (cont’d).

 Loc Source statement Object code

Figure 3.8 Sample programs illustrating linking and relocation (cont’d).

Program Linking Example

Program A Program B Program C

Label Expression LISTA, ENDA LISTB, ENDB LISTC, ENDC
REF1 LISTA local, R, PC external external
REF2 LISTB+4 external local, R, PC external
REF3 ENDA-LISTA local, A external external
REF4 ENDA-LISTA+LISTC local, A external local, R
REF5 ENDC-LISTC-10 external external local, A
REF6 ENDC-LISTC+LISTA-1 local, R external local, A
REF7 ENDA-LISTA-(ENDB-LISTB) local, A local, A external
REF8 LISTB-LISTA local, R local, R external

26
Figure 3.9 Object programs corresponding to Fig. 3.8.
Figure 3.9 Object programs corresponding to Fig. 3.8 (cont’d).
Figure 3.9 Object programs corresponding to Fig. 3.8 (cont’d).
Program Linking Example
•Fig. 3.10
•Load address for control sections
» PROGA 004000 63
» PROGB 004063 7F
» PROGC 0040E2 51
•Load address for symbols
•LISTA: PROGA+0040=4040
•LISTB: PROGB+0060=40C3
•LISTC: PROGC+0030=4112
•REF4 in PROGA
•ENDA-LISTA+LISTC=14+4112=4126
•T0000540F000014FFFFF600003F000014FFFFC0
•M00005406+LISTC

30
 Memory
Contents
address

Figure 3.10(a) Programs for Fig. 3.9 after linking and loading.
 Object programs Memory contents

(Actual address of
LISTC)

Load addresses

Figure 3.10(b) Relocation and linking operations performed on REF4 from PROGA.
Program Logic and Data Structure

•Two Passes Logic

•Pass 1: assign addresses to all external symbols
•Pass 2: perform the actual loading, relocation, and linking
•ESTAB (external symbol table)
Control section Symbol Address Length
Progam A 4000 63
LISTA 4040
ENDA 4054
Program B 4063 7F
LISTB 40C3
ENDB 40D3
Program C 40E2 51
LISTC 4112
ENDC 4124

33
Pass 1 Program Logic

•Pass 1:
•assign addresses to all external symbols
•Variables
•PROGADDR (program load address) from OS
•CSADDR (control section address)
•CSLTH (control section length)
•ESTAB
•Fig. 3.11(a)
•Process Define Record

34
Control section Symbol name Address Length
PROGA 4000 0063
LISTA 4040
ENDA 4054
PROGB 4063 007F
LISTB 40C3
ENDB 40D3
PROGC 40E2 0051
LISTC 4112
ENDC 4124
Figure 3.11(a) Algorithm for Pass 1 of a linking loader.
 Pass 1:

Figure 3.11(a) Algorithm for Pass 1 of a linking loader (cont’d)

Pass 2 Program Logic

•Pass 2:
•perform the actual loading, relocation, and linking
•Modification record
•lookup the symbol in ESTAB
•End record for a main program
•transfer address
•Fig. 3.11(b)
•Process Text record and Modification record

37
 Pass 2:

Figure 3.11(b) Algorithm for Pass 2 of a linking loader.

Improve Efficiency

•Use local searching instead of multiple searches of

ESTAB for the same symbol
•assign a reference number to each external symbol
•the reference number is used in Modification records
•Implementation
•01: control section name
•other: external reference symbols
•Example
•Fig. 3.12

39
Figure 3.12 Object programs corresponding to Fig 3.8 using reference
numbers for code modification. (Reference numbers are underlined for
easier reading.)
Figure 3.12 Object programs corresponding to Fig 3.8 using reference
numbers for code modification (cont’d). (Reference numbers are underlined
for easier reading.)
Figure 3.12 Object programs corresponding to Fig 3.8 using reference numbers for
code modification (cont’d). (Reference numbers are underlined for easier reading.)
Figure 3.12

Ref No. Symbol Address

1 PROGA 4000
2 LISTB 40C3
3 ENDB 40D3
4 LISTC 4112
5 ENDC 4124
PROGA

Ref No. Symbol Address Ref No. Symbol Address

1 PROGB 4063 1 PROGC 4063
2 LISTA 4040 2 L I S TA 4040
3 ENDA 4054 3 ENDA 4054
4 LISTC 4112 4 LISTB 40C3
5 ENDC 4124 5 ENDB 40D3
PROGB PROGC

43
3.3 Machine-Independent Loader Features

•3.3.1 Automatic library search

•3.3.2 Common option for loading and linking
3.3.1 Automatic Library Search

•Automatic Library Search

•Many linking loaders can automatically incorporate routines from
a subprogram library into the program being loaded
• A standard library
• Other libraries may be specified by control statements or by parameters to
the loader
•Also called automatic library call in some systems

45
3.3.1 Automatic Library Search (cont’d)

•Implementation
•Linking loaders 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 represented unresolved external references
•Then, the loader searches the library or libraries specified for
routines that contain the definitions of these symbols
•Note that the subroutines fetched from a library in this way may
themselves contain external references.
• It is therefore necessary to repeat the library search process until all
references are resolved.

46
3.3.1 Automatic Library Search (cont’d)

•Implementation
•The process allows the programmer to override the standard
subroutines in the library by supplying his or her own routines
•The libraries to be searched by the loader ordinarily
contain assembled or compiled versions of the
subroutines (i.e., object programs)
•For efficient searching
• Directory
•Some operating systems can keep the directory for commonly
used libraries permanently in memory
•The same technique applies equally well to the resolution
of external references to data items

47
3.3.2 Loader Options

•Many loaders allow the user to specify options that

modify the standard processing
•Many loaders have a special command language
•A separate input file to loader
•Embedded in the primary input stream
•In source program

48
3.3.2 Loader Options (cont’d)

•Examples of command language

1. INCLUDE program-name(library-name)
Direct the loader to read the designated object program from a library and
treat it as if it were part of the primary loader input
2. DELETE csdect-name
Instruct the loader to delete the named control section(s) from the set of
programs being loaded
3. CHANGE name1, name2
Cause the external symbol name1 to be changed to name2
wherever it appears in the object programs

49
 Line Source statement

Figure 2.17 Object program corresponding to Fig. 2.15

Figure 2.15 Illustration of control sections and program linking

•Suppose that a file containing the object programs in Fig.
2.17 is the primary loader input with the loader commands

INCLUDE READ(UTLIB)
INCLUDE WRITE(UTLIB)
DELETE RDREC, WRREC
CHANGE RDREC, READ
CHANGE WRREC, WRITE
3.3.2 Loader Options (cont’d)

•Examples of command language

4. LIBRARY MYLIB
Automatic inclusion of library routines to satisfy external references
Searched before the standard libraries
5. NOCALL STDDEV, PLOT, CORREL
To instruct the loader that these external references are to remain unsolved
6. Others
• Output from the loader, e.g., the map which includes control section names
and addresses
• The ability to specify the location at which execution is to begin
• Control whether or not the loader should attempt to execute the program if
errors are detected during the load

52
3.4 Loader Design Options

•3.4.1 Linkage Editor

•Perform linking prior to load time
•3.4.2 Dynamic linking
•Linking function is performed at execution time
•3.4.3 Bootstrap loader
•Be used to run stand-alone programs independent of the
operating system or the system loader

53
3.4.1 Linkage Editors

•The essential difference between a linkage editor and a

linking loader

Figure 3.13 Processing of an object program using (a) linking

loader and (b) linkage editor, 54
3.4.1 Linkage Editors (cont’d)

•A linking loaders performs

•All linking and relocation operations
•Automatic library search
•Loads the linked program directly into memory for execution
•A linkage editor
•Produces a linked version of program (often called a load module
or an executable image), which is written to a file or library for
later execution
•A simple relocating loader can be used to load the linked version
of program into memory
• The loading can be accomplished in one pass with no external symbol table
required

55
3.4.1 Linkage Editors (cont’d)

•A linkage editor
•Resolution of external references and library searching are only
performed once
•In the linked version of programs
• All external references are resolved, and relocation is indicated by some
mechanism such as modification records or a bit mask
•External references is often retained in the linked program
• To allow subsequent relinking of the program to replace control sections,
modify external references, etc.

56
3.4.1 Linkage Editors (cont’d)

•Linkage editors can perform many useful functions

besides simply preparing an object program for execution
1. The linkage editor can be used to replace the subroutines in the
linked version

INCLUDE PLANNER(PROGLIB)
DELETE PROJECT DELETE from existing PLANNER
INCLUDE PROJECT(NEWLIB) INCLUDE new version
REPLACE PLANNER(PROGLIB)

57
3.4.1 Linkage Editors (cont’d)
2. Linkage editors can also be used to build packages of
subroutines or other control sections that are generally used
together
It could be used to combine the appropriate subroutines into a package with a
command sequence

INCLUDE READR(FTNLIB)
INCLUDE WRITER(FTNLIB)
INCLUDE BLOCK(FTNLIB)
INCLUDE DEBLOCK(FTNLIB)
INCLUDE ENCODE(FTNLIB)
INCLUDE DECODE(FTNLIB)
.
.
.
SAVE FTNIO(SUBLIB)

58
3.4.1 Linkage Editors (cont’d)
3. Linkage editors often allow the user to specify that external
references are not to be resolved by automatic library search
Only the external references between user-written routines would be resolved

59
3.4.2 Dynamic Linking

•Postpone the linking function until execution time

•A subroutine is loaded and linked to the rest of the program when
it is first called
• Dynamic linking, dynamic loading, or load on call
•Allow several executing programs to share one copy of a
subroutine or library
•In object-oriented system, it allows theimplementation of
the object and its methods to be determined at the time
the program is run
•Dynamic linking provides the ability to load the routines
only when they are needed
60
 • Dynamically loaded
must be called via
Dynamic loader
(part of the
an operating system
operating
Dynamic loader service request
system)
Load-and-call • Load-and-call service
ERRHANDL a. OS examines its
Library internal tables to
determine whether or
not the routine is
User program User program
already loaded
b. Routine is loaded from
ERRHANDL
library

(a) (b)

Figure 3.14 Loading and calling of a subroutine using dynamic linking.

 c. Control is passed
from OS to the
Dynamic loader Dynamic loader Dynamic loader called subroutine
Load-and-call
d. Subroutine is finished
ERRHANDL e. Calling to a
subroutine which is
already in
memory
User program User program User program

ERRHANDL ERRHANDL ERRHANDL • Binding of the name to an

actual address is delayed
from load time until execution
time

(c) (d) (e)

Figure 3.14 Loading and calling of a subroutine using dynamic linking. (cont’d)
3.4.3 Bootstrap Loaders

•Given an idle computer with no program in memory, how

do we get things started?
•With the machine empty and idle, there is no need for program
relocation
• Some early computers required the operator to enter into memory the object
code for an absolute loader, using switches on the computer console
• On some computers, an absolute loader program is permanently resident in a
ROM
• A built-in hardware function that reads a fixed-length record from some
device into memory at a fixed location

63
3.5 Implement Examples

•MS-DOS Linker
•SunOS Linkers
•Cary MPP Linker
3.5.1 MS-DOS Linker

•Most MS-DOS compilers and assemblers (including

MASM) produce object modules, not executable machine
language programs.
•Binary image
• Translated instructions and the data of the program
• Describes the structure of the program (the grouping of segments and the use
of external references in the program)

•MS-DOS LINK is a linkage editor that combines one or

more object modules to produce a complete executable
program.
3.5.1 MS-DOS Linker (cont’d)

Record Types Description

THEADR Translator header
TYPDEF
PUBDEF External symbols and references
EXTDEF
LNAMES
SEGDEF Segment definition and grouping
GRPDEF
LEDATA
Translated instructions and data
LIDATA
FIXUPP Relocation and linking information
MODEND End of object module
Figure 3.15 MS-DOS object module.
3.5.1 MS-DOS Linker (cont’d)

•THEADR
•the name of the object module
•MODEND
•Marks the end of the module, and can contain a reference to the
entry point of the program
•TYPDEF
•The data type designed by an external name
•PUBDEF
•A list of the external symbols (public names)
•EXTDEF
•A list of the external symbols that referred to this object module
3.5.1 MS-DOS Linker (cont’d)

•LNAMES
•A list of all the segment and class names used in the program
•SEGDEF
•Describe the segment in the object module (include name, length,
and alignment)
•GRPDEF
•Specify how these segments are combined into groups
3.5.1 MS-DOS Linker (cont’d)

•LEDATA
•Contain translated instructions and data from the source program
•LIDATA
•Specify translated instructions and data that occur in a repeating
pattern
•FIXUPP
•Used to resolve external references, and address modifications
that are associated with relocation and grouping of segments
within the program.
•FIXUPP record must immediately follow the LEDATA and
LIDATA
3.5.1 MS-DOS Linker (cont’d)

•MS-DOS Linker performs its processing in two passes

•Pass 1 computes a starting address for each segment in the
program
•Pass 1 constructs a symbol table that associates an address with
each segment (using the LNAMES, SEGDEF, and GRPDEF
records) and each external symbol (using the EXTDEF and
PUBDEF records)
3.5.1 MS-DOS Linker (cont’d)
•Pass2, Link extracts the translated instructions and data from the
object modules, and builds an image of the executable program in
memory
•Pass 2 of LINK processes each LEDATA and LIDATA record
along with the corresponding FIXUPP record, places the binary
data from LEDATA and LIDATA records into the memory.
•Relocations within a segment are performed, and external
references are resolved.
•After the memory image is complete, LINK write it to the
executable (.EXE) file.
3.5.2 SunOS Linkers

•SunOS provides two linkers

•Link-editor
• It takes one or more object modules to combine them to produce a single
output module
•Run-time liker
• Used to bind dynamic executables and shared objects at execution time
3.5.2 SunOS Linkers (cont’d)

•Link-editor output modules may be one of the following

types:
1. A relocatable object module, suitable for further link-editing
2. A static executable module, with all symbolic references bound
and ready to run
3. A dynamic executable module, in which some symbolic
references may need to be bound at run time
4. A shared object, which provides services that can be bound at
run time to one or more dynamic executables
3.5.2 SunOS Linkers (cont’d)

•Linker determines what shared objects are required by the

dynamic executable, and ensures that those objects
included. It also inspects the shared objects to detect and
process any additional dependencies on other shared
objects.
•Procedure call is normally deferred until the program is in
execution.
•During link-editing, calls to globally defined procedures
are converted to references to a procedure linkage table
3.5.2 SunOS Linkers (cont’d)

•When a procedure is called for the first time, control is

passed via the procedure linkage table to the run-time
linker. The linker looks up the actual address of the called
procedure and inserts it into the linkage table.
•This process is sometimes referred to as lazy binding
3.5.3 Cary MPP Linker

•A T3E system contains a large processing elements (PEs)

•Each PE has its own local memory, PE can access the
memory of all other PEs (remote memory)
•An application program on a T3E system is normally
allocate a partition that contains of several Pes.
3.5.3 Cary MPP Linker (cont’d)

Figure 3.16 Example of data shared between Pes.

Suppose a program contains a loop that processes all 256 array

elements. PE0 could this loop for subscripts 1 through 16, PE2 could
execute the loop for subscripts 17 through 32, and so on.
3.5.3 Cary MPP Linker (cont’d)

•When a program is loaded, each PEs gets a copy of the

executable code for the program, its private data, and its
portion of the shared data.
•The MPP linker organizes blocks of code or data from the
object programs into lists.
•The blocks on each list are collected together, an address
is assigned to each block, and relocation and linking
operations are performed.
•Then, Linker writes an executable file that contains the
relocated and linked blocks.
3.5.3 Cary MPP Linker (cont’d)

PE0 PE1 PEn

Code Code Code

Private Private ... Private

data data data

Shared Shared Shared

data-0 data-1 data-n

Figure 3.17 T3E program loader on multiple PEs