Relocation (computing): Difference between revisions
looks like chapter 3 of "linkers and loaders" is no longer avaialble for online viewing - http://www.johnlevine.com/books.phtml |
|||
Line 10: | Line 10: | ||
| author = [[John R. Levine]] |
| author = [[John R. Levine]] |
||
| chapter = Chapter 3: Object Files |
| chapter = Chapter 3: Object Files |
||
| chapterurl = http://www.iecc.com/linker/linker03.html |
|||
| month = October |
| month = October |
||
| year = 1999 |
| year = 1999 |
Revision as of 18:59, 28 August 2008
In computer science, relocation is the process of replacing symbolic references or names of libraries with actual usable addresses in memory before running a program. It is typically done by the linker during compilation (at compile time), although it can be done at runtime by a relocating loader. Compilers or assemblers typically generate the executable with zero as the lower-most, starting address. Before the execution of object code, these addresses should be adjusted so that they denote the correct runtime addresses.
Relocation is typically done in two steps:
- Each object code has various sections like code, data, .bss etc. To combine all the objects to a single executable, the linker merges all sections of similar type into a single section of that type. The linker then assigns runtime addresses to each section and each symbol. At this point, the code (functions) and data (global variables) will have unique runtime addresses.
- Each section refers to one or more symbols which should be modified so that they point to the correct runtime addresses.
A fixup table -- a relocation table -- can also be provided in the header of the object code file. Each "fixup" is a pointer to an address in the object code that must be changed when the loader relocates the program. Fixups are designed to support relocation of the program as a complete unit. In some cases, each fixup in the table is itself relative to a base address of zero, so the fixups themselves must be changed as the loader moves through the table.[1] In some architectures, compilers, and executable models, a fixup that crosses certain boundaries (such as a segment boundary) or that does not lie on a word boundary is illegal and flagged as an error by the linker.[2]
See also
References
- ^
John R. Levine (1999). "Chapter 3: Object Files". Linkers and Loaders. Morgan-Kauffman. ISBN 1-55860-496-0.
{{cite book}}
: Unknown parameter|month=
ignored (help) - ^ "Borland article #15961: Coping with 'Fixup Overflow' messages". Retrieved 2007-01-15.