Module 3 Loaders and Linkers
Module 3 Loaders and Linkers
Module 3
Loaders and Linkers
Chapter 3
Loaders and Linkers
The Source Program written in assembly language or high level language will be converted to
object program, which is in the machine language form for execution. This conversion either
from assembler or from compiler, contains translated instructions and data values from the
source program, or specifies addresses in primary memory where these items are to be loaded
for execution.
1. Loading - which allocates memory location and brings the object program into
memory for execution - (Loader)
2. Linking- which combines two or more separate object programs and supplies the
information needed to allow references between them - (Linker)
3. Relocation - which modifies the object program so that it can be loaded at an
address different from the location originally specified - (Linking Loader)
A loader is a system program that performs the loading function. It brings object
program into memory and starts its execution. The role of loader is as shown in the figure 3.1.
In figure 3.1 translator may be assembler/complier, which generates the object program and
later loaded to the memory by the loader for execution. In figure 3.2 the translator is
specifically an assembler, which generates the object loaded, which becomes input to the
loader. The figure 3.3 shows the role of both loader and linker.
Object
Source Assembler
Program Loader Object
Program
program
ready for
execution
Memory
Figure 3.2: The Role of Loader with Assembler
Object
Source Assembler
Program Linker
Program
Object
program
ready for
Executable execution
Code
Loader
Memory
Figure 3.3 : The Role of both Loader and Linker
Type of Loaders
The different types of loaders are, absolute loader, bootstrap loader, relocating loader
(relative loader), and, direct linking loader. The following sections discuss the functions and
design of all these types of loaders.
Absolute Loader
The operation of absolute loader is very simple. The object code is loaded to specified
locations in the memory. At the end the loader jumps to the specified address to begin
execution of the loaded program. The role of absolute loader is as shown in the figure 3.3.1.
The advantage of absolute loader is simple and efficient. But the disadvantages are, the need
for programmer to specify the actual address, and, difficult to use subroutine libraries.
1000
Object Absolute
Program Loader
Object
program
ready for
execution
2000
Memory
Figure 3.3.1: The Role of Absolute Loader
The algorithm for this type of loader is given here. The object program and, the object program
loaded into memory by the absolute loader are also shown. Each byte of assembled code is
given using its hexadecimal representation in character form. Easy to read by human beings.
Each byte of object code is stored as a single byte. Most machine store object programs in a
binary form, and we must be sure that our file and device conventions do not cause some of the
program bytes to be interpreted as control characters.
Note
No linking and relocation needed
Records in object program performs the following
Header record
Check the Header record for program name, starting address, and length (available memory)
Text record
Bring the object program contained in the Text record to the indicated address
End record
Transfer control to the address specified in the End record.
Begin
read Header record
verify program name and length
read first Text record
while record type is <> ‘E’ do
begin
{if object code is in character form, convert into internal representation}
move object code to specified location in memory
read next object program record
end
jump to address specified in End record
end
No text record corresponds here.XXX indicates that the previous contents of these locations
remain unchanged.
THIS BOOTSTRAP READS OBJECT CODE FROM DEVICE F1 AND ENTERS IT INTO MEMORY
STARTING AT ADDRESS 80 (HEXADECIMAL). AFTER ALL OF . THE CODE FROM DEVF1 HAS BEEN
SEEN ENTERED INTO MEMORY, THE BOOTSTRAP EXECUTES A JUMP TO ADDRESS 80 TO BEGIN
EXECUTION OF . THE PROGRAM JUST LOADED. REGISTER X CONTAINS THE NEXT ADDRESS
. TO BE LOADED
This needs the design and implementation of a more complex loader. The loader must
provide program relocation and linking, as well as simple loading functions.
3.4.1 Relocation
The concept of program relocation is, the execution of the object program using any
part of the available and sufficient memory. The object program is loaded into memory
wherever there is room for it. The actual starting address of the object program is not known
until load time. Relocation provides the efficient sharing of the machine with larger memory
and when several independent programs are to be run together. It also supports the use of
subroutine libraries efficiently. Loaders that allow for program relocation are called relocating
loaders or relative loaders.
Use of modification record and, use of relocation bit, are the methods available for
specifying relocation. In the case of modification record, a modification record M is used in the
object program to specify any relocation. In the case of use of relocation bit, each instruction is
associated with one relocation bit and, these relocation bits in a Text record is gathered into bit
masks.
Modification records are used in complex machines and are also called Relocation and
Linkage Directory (RLD) specification. The format of the modification record (M) is as
follows. The object program with relocation by Modification records is also shown here.
Modification record
col 1: M
col 2-7: relocation address
col 8-9: length (halfbyte)
col 10: flag (+/-)
col 11-17: segment name
Relocation Bits
If there are many addresses needed to be modified, it is more efficient to use a relocation bit,
instead of a Modification record, to specify every relocation.
When the instruction format is fixed
1. There is a relocation bit for each word of the object program
2. Relocation bits are put together into a bit mask
3. If the relocation bit corresponding to a word of object code is set to 1, the program’s
starting address will be added to this word when the program is relocated.
The relocation bit method is used for simple machines. Relocation bit is 0: no modification is
necessary, and is 1: modification is needed. This is specified in the columns 10-12 of text
record (T), the format of text record, along with relocation bits is as follows.
Text record
col 1: T
col 2-7: starting address
col 8-9: length (byte)
col 10-12: relocation bits
col 13-72: object code
Twelve-bit mask is used in each Text record (col:10-12 – relocation bits), since each
text record contains less than 12 words, unused words are set to 0, and, any value that is to be
modified during relocation must coincide with one of these 3-byte segments. For absolute
loader, there are no relocation bits column 10-69 contains object code. The object program
with relocation by bit mask is as shown below. Observe FFC - means all ten words are to be
modified and, E00 - means first three records are to be modified.
Program linking
The Goal of program linking is to resolve the problems with external references
(EXTREF) and external definitions (EXTDEF) from different control sections.
The assembler must include information in the object program that will cause the
loader to insert proper values where they are required – in the form of Define record (D) and,
Refer record(R).
Define record
The format of the Define record (D) along with examples is as shown here.
Col. 1 D
Col. 2-7 Name of external symbol defined in this control section
Col. 8-13 Relative address within this control section (hexadecimal)
Col.14-73 Repeat information in Col. 2-13 for other external symbols
Example records
Refer record
The format of the Refer record (R) along with examples is as shown here.
Col. 1 R
Col. 2-7 Name of external symbol referred to in this control section
Col. 8-73 Name of other external reference symbols
Example records
R LISTB ENDB LISTC ENDC
R LISTA ENDA LISTC ENDC
R LISTA ENDA LISTB ENDB
Here are the three programs named as PROGA, PROGB and PROGC, which are
separately assembled and each of which consists of a single control section. LISTA, ENDA in
PROGA, LISTB, ENDB in PROGB and LISTC, ENDC in PROGC are external definitions in
each of the control sections. Similarly LISTB, ENDB, LISTC, ENDC in PROGA, LISTA,
ENDA, LISTC, ENDC in PROGB, and LISTA, ENDA, LISTB, ENDB in PROGC, are
external references. These sample programs given here are used to illustrate linking and
relocation. The following figures give the sample programs and their corresponding object
programs. Observe the object programs, which contain D and R records along with other
records.
Keeping these details work through the details of other references and values of these
references are the same in each of the three programs.
Dr. C.K. SRINIVAS Professor. DEPT OF CSE BITM, BALLARI 15
Chapter 4 LINKERS & LOADERS
The algorithm for a linking loader is considerably more complicated than the absolute loader
program, which is already given. The concept given in the program linking section is used for
developing the algorithm for linking loader. The modification records are used for relocation
so that the linking and relocation functions are performed using the same mechanism.
Linking Loader uses two-passes logic. ESTAB (external symbol table) is the main data
structure for a linking loader.
ESTAB - ESTAB for the example (refer three programs PROGA PROGB and PROGC) given
is as shown below. The ESTAB has four entries in it; they are name of the control section, the
symbol appearing in the control section, its address and length of the control section
begin
set CSADDR to PROGADDR
set EXECADDR to PROGADDR
while not end of input do
begin
read next input record {Header record for control section}
set CSLTH to control section length
while record type != ‘E’ do
begin
if record type = ‘T’ then
begin
{if object code is in character form, convert into internal representation}
Move object code from record to location (CSADR + specified address)
end {if ‘T’}
else if record type = ‘M’ do
begin
search ESTAB for modifying symbol name
if found then
add or subtract symbol value at location
(CSADR + specified address)
else set error flag (undefined external symbol)
end {if ‘M’}
end {if ‘E’}
if an address is specified {in end record} then
set EXECADDR to { CSADDR + specified address}
add CSLTH to CSADDR
end {while not EOF}
jump to location given by EXECADDR {to start the execution of loaded program}
end {Pass 2}
The object programs for PROGA, PROGB and PROGC are shown below, with above
modification to Refer record ( Observe R records).
Loader Options
Loader options allow the user to specify options that modify the standard processing. The
options may be specified in three different ways.
They are,
1. Specified using a command language,
2. Specified as a part of job control language that is processed by the operating system, and
3. Can be specified using loader control statements in the source program.
• 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
• LIBRARY MYLIB – search MYLIB library before standard libraries.
• NOCALL STDDEV, PLOT, CORREL – no loading and linking of unneeded routines
Here is one more example giving, how commands can be specified as a part of object
file, and the respective changes are carried out by the loader.
LIBRARY UTLIB
INCLUDE READ (UTLIB)
INCLUDE WRITE (UTLIB)
DELETE RDREC, WRREC
CHANGE RDREC, READ
CHANGE WRREC, WRITE
NOCALL SQRT, PLOT
The commands are, use UTLIB ( say utility library), include READ and WRITE
control sections from the library, delete the control sections RDREC and WRREC from the
load, the change command causes all external references to the symbol RDREC to be changed
to the symbol READ, similarly references to WRREC is changed to WRITE, finally, no call to
the functions SQRT, PLOT, if they are used in the program.
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.
• 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
• 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
• reduce 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 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.
• 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.
• 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.
(a) Issue a load-and-call service request (b) Load the called subroutine into memory
(c) Control is passed to the loaded subroutine. (d) Control is returned to the loader and later
returned to the user program
(e) The called subroutine this time is already loaded.
Dr. C.K. SRINIVAS Professor. DEPT OF CSE BITM, BALLARI 24
Chapter 4 LINKERS & LOADERS
Bootstrap Loaders
If the question, how is the loader itself loaded into the memory? is asked, then the
answer is, when computer is started – with no program in memory, a program present in ROM
( absolute address) can be made executed – may be OS itself or A Bootstrap loader, which in
turn loads OS and prepares it for execution. The first record (or records) is generally referred to
as a bootstrap loader – makes the OS to be loaded. Such a loader is added to the beginning of
all object programs that are to be loaded into an empty and idle system.
Implementation Examples
This section contains brief description of loaders and linkers for actual computers.
They are, MS-DOS Linker - Pentium architecture, SunOS Linkers - SPARC architecture, and,
Cray MPP Linkers – T3E architecture.
MS-DOS Linker
This explains some of the features of Microsoft MS-DOS linker, which is a linker for
Pentium and other x86 systems. Most MS-DOS compilers and assemblers (MASM) produce
object modules, and they
are stored in .OBJ files. MS-DOS LINK is a linkage editor that combines one or more object
modules to produce a complete executable program - .EXE file; this file is later executed for
results.
The following table illustrates the typical MS-DOS object module
THEADR specifies the name of the object module. MODEND specifies the end of the
module. PUBDEF contains list of the external symbols (called public names). EXTDEF
contains list of external symbols referred in this module, but defined elsewhere. TYPDEF the
data types are defined here. SEGDEF describes segments in the object module (includes name,
length, and alignment). GRPDEF includes how segments are combined into groups. LNAMES
contains all segment and class names. LEDATA contains translated instructions and data.
LIDATA has above in repeating pattern. Finally, FIXUPP is used to resolve external
references.
SunOS Linkers
SunOS Linkers are developed for SPARC systems. SunOS provides two different
linkers – link-editor and run-time linker.
2. A static executable – with all symbolic references bound and ready to run
4. A shared object – which provides services that can be, bound at run time to one ore
more dynamic executables
An object module contains one or more sections – representing instructions and data
area from the source program.
Each section has a set of attributes, such as ‘executable’ and ‘writeable’. The object module
also includes a list of relocation and linking information, external symbol table.
Run-time linker uses dynamic linking approach. Run-time linker binds dynamic
executables and shared objects at execution time. Performs relocation and linking operations to
prepare the program for execution.
Cray MPP (massively parallel processing) Linker is developed for Cray T3E systems. A T3E
system contains large number of parallel processing elements (PEs).
The below figure shows how the data (i.e. 256 dimensional array) is divided into 16 PE’s
Each PE has local memory and has access to remote memory (memory of other PEs). The
processing is divided among PEs - contains shared data and private data. The loaded program
gets copy of the executable code, its private data and its portion of the shared data. The below
figure shows this arrangement.
The MPP linker organizes blocks containing executable code, private data and shared data. The
linker then writes an executable file that contains the relocated and linked blocks. The
executable file also specifies the number of PEs required and other control information. The
linker can create an executable file that is targeted for a fixed number of PEs, or one that
allows the partition size to be chosen at run time. Latter type is called plastic executable.
QUESTIONS
2. What are the basic functions of a loader? Develop an algorithm for a bootstrap 10
loader. (FEB 2005. JUNE 2008 JAN 2009 JAN 2010)
3. How relocation is done using bit masking and modification records? (JAN 2005) 10
4. With figure explain how loading & calling of a subroutine can be done using 10
dynamic linking.(JUNE 2008 JAN 2009)
5. What is relocating loader? Explain with example two methods of relocating loader. 10
(JUNE 2008 JAN 2009, Dec2011)
7. What are the basic functions of a loader? Develop an algorithm for a bootstrap 10
loader.(JAN 2010)
8. Explain the procedure of program linking when the subprograms use external 12
references. (JUNE 2010)
9. Write short notes on
I. Linkage loader (JUNE 2010)
04
II. Automatic library search 08
III. MS-DOS - Linker 05
IV. Linkage editor. 05
10. Enlist any four loader options commands. (JUNE 2010) 04
11. Distinguish between linking loader and linkage editor. (JAN 2009) 04