Relocation (computing): Difference between revisions

Revision as of 23:51, 12 May 2025

Latest revision as of 17:27, 24 July 2025

(2 intermediate revisions by 2 users not shown)

Line 18:

The relocation table is a list of addresses created by a [[compiler]] or [[Assembler (computer programming)#Assembler|assembler]] and stored in the object or executable file. Each entry in the table references an absolute address in the object code that must be changed when the loader relocates the program so that it will refer to the correct ___location. Entries in the relocation table are known as ''fixups'' and 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.<ref name="Levine_1999_CH1_CH3"/>

In some architectures, a fixup that crosses certain boundaries (such as a segment boundary) or that is not aligned on a word boundary is illegal and flagged as an error by the linker.<ref name="Borland_2007"/>

=== DOS and 16-bit Windows ===

Far [[pointer (computer programming)|pointer]]s ([[32-bit]] pointers with [[x86 memory segmentation|segment]]:offset, used to address 20-bit 640 &nbsp;[[kilobyte|KB]] [[computer storage|memory]] space available to [[DOS]] [[computer program|program]]sprograms), which point to code or data within a [[DOS executable]] ([[EXE]]), do not have absolute segments, because the actual [[memory address|address]] of code/ or data depends on where the program is loaded in memory and this is not known until the program is loaded.

Instead, segments are relative values in the DOS EXE file. These segments need to be corrected, when the executable has been loaded into memory. The EXE [[loader (computing)|loader]] uses a relocation table to find the segments whichthat need to be adjusted.

=== 32-bit Windows ===

With 32-bit Windows operating systems, it is not mandatory to provide relocation tables for EXE files, since they are the first image loaded into the virtual address space and thus will be loaded at their preferred base address.

For both [[Dynamic Link Library|DLL]]s and for EXEs which opt into [[address space layout randomization]] (ASLR), an [[exploit (computer security)|exploit]] mitigation technique introduced with [[Windows Vista]], relocation tables once again become mandatory because of the possibility that the binary may be dynamically moved before being executed, even though they are still the first thing loaded in the virtual address space.

Windows executables can be marked as ASLR-compatible. The ability exits in Windows 8 and newer to enable ASLR even for applications not marked as compatible.<ref>{{cite web |url=https://cloud.google.com/blog/topics/threat-intelligence/six-facts-about-address-space-layout-randomization-on-windows |title=Six Facts about Address Space Layout Randomization on Windows |date=March 17, 2020 |access-date=July 24, 2020}}</ref> To run successfully in this envoronment the relocation sections cannot be omitted by the compiler.<!--[[User:Kvng/RTH]]-->

=== 64-bit Windows ===

When running native 64-bit binaries on Windows Vista and above, ASLR is mandatory{{Citation needed|date=January 2014}}, and thus relocation sections cannot be omitted by the compiler.

=== Unix-like systems ===

Line 68 ⟶ 67:

{{Reflist|refs=

<ref name="Intel_iRMX">{{cite book |title=iRMX 86 Application Loader Reference Manual |publisher=[[Intel]] |url=http://bitsavers.informatik.uni-stuttgart.de/pdf/intel/iRMX/iRMX_86_Rev_6_Mar_1984/146196_Burst/iRMX_86_Application_Loader_Reference_Manual.pdf |access-date=2020-01-11 |url-status=live |archive-url=https://web.archive.org/web/20200111215002/http://bitsavers.informatik.uni-stuttgart.de/pdf/intel/iRMX/iRMX_86_Rev_6_Mar_1984/146196_Burst/iRMX_86_Application_Loader_Reference_Manual.pdf |archive-date=2020-01-11 |chapter=Types of Object Code |pages=((1{{hyphen}}2–1{{hyphen}}3)) |quote=[…] ''Absolute code'', and an absolute object module, is code that has been processed by LOC86 to run only at a specific ___location in memory. The [[Loader (computing)|Loader]] loads an absolute object module only into the specific ___location the module must occupy. ''[[Position-independent code]]'' (commonly referred to as PIC) differs from absolute code in that PIC can be loaded into any memory ___location. The advantage of PIC over absolute code is that PIC does not require you to reserve a specific block of memory. When the Loader loads PIC, it obtains [[iRMX&nbsp;86]] memory segments from the pool of the calling task's job and loads the PIC into the segments. A restriction concerning PIC is that, as in the [[PL/M-86]] COMPACT model of segmentation […], it can have only one code segment and one data segment, rather than letting the base addresses of these segments, and therefore the segments themselves, vary dynamically. This means that PIC programs are necessarily less than 64K bytes in length. PIC code can be produced by means of the BIND control of LINK86. ''Load-time locatable code'' (commonly referred to as LTL code) is the third form of object code. LTL code is similar to PIC in that LTL code can be loaded anywhere in memory. However, when loading LTL code, the Loader changes the base portion of pointers so that the pointers are independent of the initial contents of the registers in the microprocessor. Because of this fixup (adjustment of base addresses), LTL code can be used by tasks having more than one code segment or more than one data segment. This means that LTL programs may be more than 64K bytes in length. [[FORTRAN 86]] and [[Pascal 86]] automatically produce LTL code, even for short programs. LTL code can be produced by means of the BIND control of LINK86. […]}}</ref>

<ref name="Levine_1999_CH1_CH3">{{cite book |author-last=Levine |author-first=John R. |author-link=John R. Levine |title=Linkers and Loaders |date=2000 |orig-date=October 1999 |edition=1 |publisher=[[Morgan Kaufmann]] |series=The Morgan Kaufmann Series in Software Engineering and Programming |___location=San Francisco, California, USA |isbn=1-55860-496-0 |oclc=42413382 |chapter=Chapter 1: Linking and Loading & Chapter 3: Object Files |pages=5<!-- , --> |url=https://www.iecc.com/linker/ |access-date=2020-01-12 |url-status=live |archive-url=https://archive.today/20121205032107/http://www.iecc.com/linker/ |archive-date=2012-12-05}} Code: [https://archive.today/20200114225034/https://linker.iecc.com/code.html][ftp://ftp.iecc.com/pub/linker/]{{dead link|date=May 2025|bot=medic}}{{cbignore|bot=medic}} Errata: [https://linker.iecc.com/<!-- https://archive.today/20200114224817/https://linker.iecc.com/ 2020-01-14 -->]</ref>

<ref name="Borland_2007">{{cite web |author=Borland |author-link=Borland |title=Borland article #15961: Coping with 'Fixup Overflow' messages. |orig-date=1998-07-02 |date=1999-09-01 |series=Technical Information Database - Product: Borland C++ 3.1 |work=community.borland.com |id=TI961C.txt #15961 |url=http://vmlinux.org/~jakov/community.borland.com/15961.html |access-date=2007-01-15 |url-status=live |archive-url=https://web.archive.org/web/20080707030831/http://vmlinux.org/~jakov/community.borland.com/15961.html |archive-date=2008-07-07}}</ref>

<ref name="ELF">{{cite web |title=Executable and Linkable Format (ELF) |series=Tool Interface Standards (TIS) Portable Formats Specification, Version 1.1 |website=skyfree.org |url=http://www.skyfree.org/linux/references/ELF_Format.pdf |access-date=2018-10-01 |url-status=live |archive-url=https://web.archive.org/web/20191224125108/http://www.skyfree.org/linux/references/ELF_Format.pdf |archive-date=2019-12-24}}</ref>