3.
4 Loader Design Options
3.4.1 Linkage Editors
3.4.2 Dynamic Linking
3.4.3 Bootstrap Loaders
Loader Design Options (Cont.)
Linking loaders
Linkage editors
Perform all linking and relocation at load time
Perform linking before the program is loaded for
execution.
Dynamic linking
Perform linking at execution time
3.4.1 Linkage Editors
Linking Loader
Performs all linking and relocation operations, including
library search if specified, and loads the linked program
directly into memory for execution
Linkage Editors
Produces a linked version of the program (often called a
load module or an executable image), which is written to
a file or library for later execution
Linkage Editors (Cont.)
A linkage editor
Perform relocation of all control sections relative
to the start of the linked program,
Resolve all external reference
Output a relocatable module for later execution
A simple relocating loader can be used to
load the program into memory
One-pass without external symbol table required
Linking Loader vs. Linkage Editor
Linking Loader vs. Linkage Editor
Linking loader
Searches libraries and resolves external
references every time the program is executed.
Avoid the writing and reading the linked program.
Linkage editor
Resolution of external reference and library
searching are only performed once
Linking Loader vs. Linkage Editor
(Cont.)
Linking loader
Suitable when a program is reassembled for
nearly every execution
In a program development and testing environment
When a program is used so infrequently that it is not
worthwhile to store the assembled and linked version.
Linkage editor
If a program is to be executed many times
without being reassembled
Additional Functions of Linkage Editors
Replacement of subroutines in the linked
program
Construction of a package for subroutines
generally used together
Specification of external references not to be
resolved by automatic library search
Additional Functions of Linkage Editors
(Cont.)
Replacement of subroutines in the linked program
For example: improve a subroutine (PROJECT) of a
program (PLANNER) without going back to the original
versions of all of the other subroutines
INCLUDE PLANNER(PROGLIB)
DELETE
PROJECT
{delete from existing PLANNER}
INCLUDE PROJECT(NEWLIB)
{include new version}
REPLACE PLANNER(PROGLIB)
=> New version of PLANNER
Additional Functions of Linkage Editors
(Cont.)
Build packages of subroutines or other control
sections that are generally used together
For example: build a new linked module FINIO instead of
search all subroutines in FINLIB
INCLUDE
INCLUDE
INCLUDE
INCLUDE
INCLUDE
INCLUDE
.
SAVE
READR(FTNLIB)
WRITER(FTNLIB)
BLOCK(FTNLIB)
DEBLOCK(FTNLIB)
ENCODE(FTNLIB)
DECODE(FTNLIB)
FTNIO(SUBLIB)
Additional Functions of Linkage Editors
(Cont.)
Specify that external references are not to be
resolved by automatic library search
Can avoid multiple storage of common libraries
in programs.
If 100 programs using the routines on the same library
A total copy of 100 libraries would to stored, waste space
Need a linking loader to combine the common
libraries at execution time.
Linking Time
Linkage editors : before load time
Linking loaders : at load time
Dynamic linking : after load time
A scheme that postpones the linking function
until execution time.
A subroutine is loaded and linked to the rest of
the program when it is first called
Other names: dynamic loading, load on call
3.4.2 Dynamic Linking
Advantages
Load the routines when they are needed, the time
and memory space will be saved.
Avoid the necessity of loading the entire library
for each execution
i.e. load the routines only when they are needed
Allow several executing programs to share one
copy of a subroutine or library (Dynamic Link
Library, DLL)
Implementation of Dynamic Linking
Need the help of OS
Instead of executing a JSUB instruction, the program
makes a load-and-call service request to the OS
Dynamic loader is one part of the OS
OS should provide load-and-call system call
The parameter of this request is the symbolic name of the
routine to be called
Processing procedures of load-and-call:
Pass control to OS
s dynamic loader
OS checks the routine in memory or not.
If in memory, pass control to the routine.
If not, load the routine and pass control to the routine.
Implementation of Dynamic Linking
(Cont.)
Pass the control: (Fig. 3.14)
Fig. 3.14 (a) User program -> OS (dynamic loader)
Fig. 3.14 (b) OS: load the subroutine
Fig. 3.14 (c) OS -> Subroutine
Fig. 3.14 (d) Subroutine -> OS -> User program
Fig. 3.14 (e) A second call to the same routine may not
require load operation
After the subroutine is completed, the memory that
was allocated to load it may be released
A second call to the same routine may not require load
operation
Loading and Calling a Subroutine
Using Dynamic Linking
Issue a load-andcall request
Load the routine from
the specified library
Loading and Calling a Subroutine
Using Dynamic Linking (Cont.)
Jump back to the
dynamic loader
Jump to the
loaded routine
Jump back to the
user program
Second call to this subroutine
may not require load operation.
Dynamic Linking (Cont.)
The association of an actual address with the
symbolic name of the called routine is not
made until the call statement is executed.
Binding of the name to an actual address is
delayed from load time until execution time.
Delayed binding
Requires more overhead since OS must intervene
in the calling process.
3.4.3 Bootstrap Loaders
How is loader itself loaded into memory?
By OS
How is OS itself loaded into memory?
Bootstrap loader
3.4.3 Bootstrap Loaders (Cont.)
On some computers, an absolute loader is
permanently resident in ROM
When power-on, the machine begins to execute
this ROM program
Inconvenient to change a ROM program if
modifications in the absolute loader are required.
3.4.3 Bootstrap Loaders (Cont.)
An intermediate solution
Have a built-in hardware function that reads a fixedlength record from some device into memory at a fixed
location, then jump to execute it.
If the loading process requires more instructions, the first
record causes the reading of the others, and these in turn
can cause the reading of still more records
This record contains machine instructions that load the absolute
program that follows.
Hence the term bootstrap.
The first record (or records) is generally referred to as a
bootstrap loader.
Appendix
Example of Programs Using Libraries
Example of Programs Using Libraries
#include <stdio.h>
main.c
extern int a();
extern int b();
main()
{
a.c
int a()
{
return 5;
}
int a1()
{
return 8;
}
int ret1, ret2;
ret1=a();
ret2=b();
printf("\n ret from a()= %d", ret1);
printf("\n ret from b()= %d", ret2);
}
b.c
int b()
{
return 5;
}
Example of Programs Using Libraries
(Cont.)
Compile source programs to object programs
Create/add/replace object programs into library
under SunOS
ar r libtmp.a a.o b.o
List contents of library under SunOS
gcc c main.c
gcc c a.c
gcc c b.c
ar t libtmp.a
Delete object programs from library under SunOS
ar d libtmp.a b.o
Example of Programs Using Libraries
(Cont.)
Using library in programs
Linking editor
Ex. gcc main.o libtmp.a o prog
Ex. gcc main.o L. ltmp o prog
ld under SunOS
References
man gcc under SunOS
man ar under SunOS
man ld under SunOS
