http://en.wikipedia.org/wiki/Linker_(computing)
Linker (computing)
In computer science, a linker or link editor is a computer program that takes one or moreobject files generated by a compiler and combines them into a single executableprogram.
A simpler version that wrote its output directly to memory was called the loader, though loading is typically considered a separate process.[1]
Contents
[hide]Overview
Computer programs typically comprise several parts or modules; all these parts/modules need not be contained within a single object file, and in such case refer to each other by means of symbols. Typically, an object file can contain three kinds of symbols:
- defined symbols, which allow it to be called by other modules,
- undefined symbols, which call the other modules where these symbols are defined, and
- local symbols, used internally within the object file to facilitate relocation.
For most compilers, each object file is the result of compiling one input source code file. When a program comprises multiple object files, the linker combines these files into a unified executable program, resolving the symbols as it goes along.
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 exist for diverse purposes, 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). This pass is usually omitted on hardware offering virtual memory: every program is put into its own address space, so there is no conflict even if all programs load at the same base address. This pass may also be omitted if the executable is a position independent executable.
On some Unix variants, such as SINTRAN III, the process performed by a linker (assembling object files into a program) was calledloading (as in loading executable code onto a file).[2] Additionally, in some operating systems the same program handles both the jobs of linking and loading a program (dynamic linking).
Dynamic linking
Many 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 code 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. Dynamic linking needs no linker.
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.
There are also disadvantages:
- Known on the Windows platform as "DLL Hell", an incompatible updated DLL will break executables that depended on the behavior of the previous DLL.
- A program, together with the libraries it uses, might be certified (e.g. as to correctness, documentation requirements, or performance) as a package, but not if components can be replaced. (This also argues against automatic OS updates in critical systems; in both cases, the OS and libraries form part of a qualified environment.)
Relaxation
As the compiler has no information on the layout of objects in the final output, it cannot take advantage of shorter or more efficient instructions that place a requirement on the address of another object. For example, a jump instruction can reference an absolute address or an offset from the current location, and the offset could be expressed with different lengths depending on the distance to the target. By generating the most conservative instruction (usually the largest relative or absolute variant, depending on platform) and adding relaxation hints, it is possible to substitute shorter or more efficient instructions during the final link. This step can be performed only after all input objects have been read and assigned temporary addresses; the relaxation pass subsequently re-assigns addresses, which may in turn allow more relaxations to occur. In general, the substituted sequences are shorter, which allows this process to always converge on the best solution given a fixed order of objects; if this is not the case, relaxations can conflict, and the linker needs to weigh the advantages of either option.
Linkage Editor
In IBM mainframe environments such as OS/360 this type of program is known as a linkage editor. However, a linkage editor, as the name implies, had the additional capability of allowing the addition, replacement, and/or deletion of individual program sections. Operating systems such has OS/360 had a different format for executable load-modules, in that they contained supplementary data about the component sections of a program, so that an individual program section could be replaced, and other parts of the program updated so that relocatable addresses and other such references could be corrected by the linkage editor, as part of the process.
One advantage of this is that it would allow a program to be maintained without having to keep all of the intermediate object files, or without having to re-compile program sections that hadn't changed. It also permitted program updates to be distributed in the form of small card decks, containing only the object module to be replaced. In such systems, object code was in the form and format of punched-card decks, so that updates could be introduced into a system using that medium. In later releases of OS/360 and in subsequent systems, load-modules contained additional data about versions of components modules, to create a traceable record of updates.
Note: the term "linkage editor" should not be construed as implying that the program operated in a user-interactive mode (like, for example, a text editor). It was strictly intended for batch-mode execution.
See also
- compile and go loader
- Dynamic library
- GNU linker
- Library
- Name decoration
- Relocation
- Relocation table
- Prelinking
- Static library
Notes
- ^ IBM Corporation (1972). IBM OS Linkage Editor and Loader.
- ^ BRF-LINKER User Manual. ND-60.196.01. 08/84.
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]
- Douglas 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. 2000 [2]
- Leon Presser, John R. White: Linkers and Loaders. ACM Computing Surveys, Volume 4, Number 3, September 1972, pp. 149–167 [3]
- Norman Ramsey, Relocating Machine Instructions by Currying. (1996) [4]
- David Salomon, Assemblers and Loaders. 1993 [5]
External links
 | Look up linker in Wiktionary, the free dictionary. |
- Ian Lance Taylor's Linkers blog entries
- Linkers and Loaders by Sandeep Grover
- Another Listing of Where to Get a Complete Collection of Free Tools for Assembly Language Development
| |||||
| ||||||||
237
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
