Linking & Loading

CS-502 Operating Systems

{Silbershatz et al barely touch on this topic in §8.1

Tanenbaum does not address it at all}

CS-502 Fall 2007 Linking and Loading 1

 What happens to your program …

…after it is compiled, but before it

can be run?

CS-502 Fall 2007 Linking and Loading 2

 Executable files

• Every OS expects executable files to have a specific

format
– Header info
• Code locations
• Data locations
– Code & data
– Symbol Table
• List of names of things defined in your program and where they
are located within your program.
• List of names of things defined elsewhere that are used by your
program, and where they are used.

CS-502 Fall 2007 Linking and Loading 3

 Example
#include <stdio.h> • Symbol defined in
your program and
used elsewhere
int main () { • main

printf (“hello,
world\n”)
• Symbol defined
elsewhere and used by
your program
• printf
}

CS-502 Fall 2007 Linking and Loading 4

 Example
#include <stdio.h> • Symbol defined in
extern int errno; your program and
used elsewhere
int main () {
• main

printf (“hello,
world\n”) • Symbol defined
elsewhere and used by
<check errno for your program
errors>
• printf
}
• errno
CS-502 Fall 2007 Linking and Loading 5
 Two-step operation
(in most systems)

• Linking: Combining a set of programs, including

library routines, to create a loadable image
a) Resolving symbols defined within the set
b) Listing symbols needing to be resolved by loader

• Loading: Copying the loadable image into

memory, connecting it with any other programs
already loaded, and updating addresses as needed
– (In Unix) interpreting file to initialize the process
address space
– (in all systems) kernel image is special (own format)

CS-502 Fall 2007 Linking and Loading 6

 From source code to a process
• Binding is the act of connecting names Source
(.c, .cc)
to addresses
• Most compilers produce relocatable
Compiler
object code
• Addresses relative to zero
Object Other Objects
• The linker combines multiple object (.o) (.o)
files and library modules into a single
executable file
• Addresses also relative to zero Linker Static libraries
(.a)
• The Loader reads the executable file
– Allocates memory Executable
– Maps addresses within file to memory Dynamic libraries
addresses Loader (.dll)
– Resolves names of dynamic library
items In-memory Image

CS-502 Fall 2007 Linking and Loading 7

 Static Linking and Loading
Printf.c HelloWorld.c
gcc Static gcc
Library
Printf.o ar HelloWorld.o
Linke
r
a.Out
(or name of
your command)
Loader
Memory
CS-502 Fall 2007 Linking and Loading 8
 Classic Unix
• Linker lives inside of cc or gcc command
• Loader is part of exec system call
• Executable image contains all object and library
modules needed by program
• Entire image is loaded at once

• Every image contains its own copy of common

library routines
• Every loaded program contain duplicate copy of
library routines
CS-502 Fall 2007 Linking and Loading 9
 Dynamic Loading

• Routine is not loaded until it is called

• Better memory-space utilization; unused
routine is never loaded.
• Useful when large amounts of code are
needed to handle infrequently occurring
cases.
• Silbershatz says [incorrectly]
• No special support from the operating system is
required
• Must be implemented through program design
CS-502 Fall 2007 Linking and Loading 10
 Program-controlled Dynamic Loading

• Requires:
– A load system call to invoke loader (not in Unix)
– ability to leave symbols unresolved and resolve at run time (not in
Unix)
• E.g.,
void myPrintf (**arg) {
static int loaded = 0;
if (!loaded ) {
load (“printf”);
loaded = 1;
printf(arg);
}
}

CS-502 Fall 2007 Linking and Loading 11

 Linker-assisted Dynamic Loading

• Programmer marks modules as “dynamic”

to linker
• For function call to a dynamic function
• Call is indirect through a link table
• Each link table entry is initialized with address of
small stub of code to locate and load module.
• When loaded, loader replaces link table entry with
address of loaded function
• When unloaded, loader restores table entry with stub
address
• Works only for function calls, not static data
CS-502 Fall 2007 Linking and Loading 12
 Example – Linker-assisted loading
(before)

Your program Link table

Stub
void main () {
void load() {
…
printf (…); load(“IOLib”);
…
} }

CS-502 Fall 2007 Linking and Loading 13

 Example – Linker-assisted loading
(after)

Your program Link table

void main () {

printf (…);
IOLib
read() {…}
} printf() {…}
scanf() {…}

CS-502 Fall 2007 Linking and Loading 14

 Shared Libraries

• Observation – “everyone” links to standard

libraries (libc.a, etc.)
• These consume space in
• every executable image
• every process memory at runtime

• Would it be possible to share the common

libraries?
– Automatically load at runtime?
CS-502 Fall 2007 Linking and Loading 15
 Shared libraries (continued)

• Libraries designated as “shared”

• .so, .dll, etc.
• Supported by corresponding “.a” libraries containing
symbol information
• Linker sets up symbols to be resolved at
runtime
• Loader: Is library already in memory?
– If yes, map into new process space
• “map,” an operation to be defined later in course
– If not, load and then map
CS-502 Fall 2007 Linking and Loading 16
 Run-time Linking/Loading
Printf.c HelloWorld.c
gcc gcc

Printf.o HelloWorld.o
Linker
ar Save disk space.
a.Out Startup faster.
Shared Might not need all.
Library (or name of
your command)
Run-time
Loader Loader

Memory
CS-502 Fall 2007 Linking and Loading 17
 Dynamic Linking

• Complete linking postponed until execution time.

• Stub used to locate the appropriate memory-
resident library routine.
• Stub replaces itself with the address of the routine,
and executes the routine.
• Operating system needs to check if routine is in
address space of process
• Dynamic linking is particularly useful for
libraries.
CS-502 Fall 2007 Linking and Loading 18
 Dynamic Shared Libraries

• Static shared libraries requires address

space pre-allocation
• Dynamic shared libraries – address binding
at runtime
– Code must be position independent
– At runtime, references are resolved as
• Library_relative_address + library_base_address

CS-502 Fall 2007 Linking and Loading 19

 Overlays
(primarily of historical interest)

• Keep in memory only those instructions and data

that are needed at any given time.
• Needed when process is larger than amount of
memory allocated to it.
• Can be implemented by user
– no special support needed from operating system, but
– programming design of overlay structure is complex
• Can be done with OS help – think about Unix exec
system call

CS-502 Fall 2007 Linking and Loading 20

 Linking – Summary

• Linker – key part of OS – not in kernel

– Combines object files and libraries into a
“standard” format that the OS loader can
interpret
– Resolves references and does static relocation
of addresses
– Creates information for loader to complete
binding process
– Supports dynamic shared libraries
CS-502 Fall 2007 Linking and Loading 21
 Loader

• An integral part of the OS

• Resolves addresses and symbols that could
not be resolved at link-time
• May be small or large
• Small: Classic Unix
• Large: Linux, Windows XP, etc.
• May be invoke explicitly or implicitly
• Explicitly by stub or by program itself
• Implicitly as part of exec

CS-502 Fall 2007 Linking and Loading 22

 Questions?

CS-502 Fall 2007 Linking and Loading 23