Linker

From Wikipedia, the free encyclopedia

Figure of the linking process, where object files and static libraries are assembled into a new library or executable.

In computer science, a linker or link editor is a program that takes one or more objects generated by compilers and assembles them into a single executable program.

In IBM mainframe environments such as OS/360 this program is known as a linkage editor.

(On Unix variants the term loader is often used as a synonym for linker. Because this usage blurs the distinction between the compile-time process and the run-time process, this article will use linking for the former and loading for the latter.)

The objects are program modules containing machine code and information for the linker. This information comes mainly in the form of symbol definitions, which come in two varieties:

Defined or exported symbols are functions or variables that are present in the module represented by the object, and which should be available for use by other modules.
Undefined or imported symbols are functions or variables that are called or referenced by this object, but not internally defined.

In short, the linker's job is to resolve references to undefined symbols by finding out which other object defines a symbol in question, and replacing placeholders with the symbol's address.

Linkers can take objects from a collection called a library. Some linkers do not include the whole library in the output; they only include its symbols that are referenced from other object files or libraries. Libraries for diverse purposes exist, and one or more system libraries are usually linked in by default.

The linker also takes care of arranging the objects in a program's address space. This may involve relocating code that assumes a specific base address to another base. Since a compiler seldom knows where an object will reside, it often assumes a fixed base location (for example, zero). Relocating machine code may involve re-targeting of absolute jumps, loads and stores.

The executable output by the linker may need another relocation pass when it is finally loaded into memory (just before execution). On hardware offering virtual memory this is usually omitted, though—every program is put into its own address space, so there is no conflict even if all programs load at the same base address.

1 Dynamic linking
2 See also
3 References
4 External links

[edit] Dynamic linking

Modern operating system environments allow dynamic linking, that is the postponing of the resolving of some undefined symbols until a program is run. That means that the executable still contains undefined symbols, plus a list of objects or libraries that will provide definitions for these. Loading the program will load these objects/libraries as well, and perform a final linking.

This approach offers two advantages:

Often-used libraries (for example the standard system libraries) need to be stored in only one location, not duplicated in every single binary.
If an error in a library function is corrected by replacing the library, all programs using it dynamically will benefit from the correction after restarting them. Programs that included this function by static linking would have to be re-linked first.

[edit] See also

[edit] References

David William Barron, Assemblers and Loaders. 1972, Elsevier.
C. W. Fraser and D. R. Hanson, A Machine Independent Linker. Software-Practice and Experience 12, 4 (April 1982).
IBM Corporation, Operating System 360, Linkage Editor, Program Logic Manual, 1967 [1]
D.W. Jones, Assembly Language as Object Code. Software-Practice and Experience 13, 8 (August 1983)
John R. Levine: Linkers and Loaders, Morgan-Kauffman, ISBN 1-55860-496-0
Leon Presser, John R. White: Linkers and Loaders. ACM Computing Surveys, Volume 4, Number 3, September 1972, pp.149-167 [2]
Norman Ramsey, Relocating Machine Instructions by Currying. (1996) [3]
David Salomon, Assemblers and Loaders. 1993 [4]