a relocation

When the compiler assembles one source file into a .o, it writes the machine code for a call like foo() but it cannot yet fill in foo's address, because foo lives in another file that has not been placed in memory yet. So it leaves a hole and writes a note that says 'here, at this offset, patch in the address of foo'. That note is a relocation. A relocation is an instruction to a later stage to fix up a specific spot in the code or data once the real address is known.

Each relocation entry records three things: an offset (where in the section the hole is), a symbol (whose address goes there, like foo), and a type that says exactly how to compute the value — for example, write the absolute 64-bit address, or write a 32-bit difference relative to the current instruction (PC-relative), possibly with an addend added in. ELF keeps these in sections named after their target, such as .rela.text for relocations that patch .text. The linker processes them at link time: now that it has decided where every section and symbol will sit, it visits each relocation, computes the final value, and writes it into the hole. Relocation types are architecture-specific (you will see names like R_X86_64_PC32 or R_X86_64_GLOB_DAT).

It matters because relocations are the glue that turns a pile of independently compiled fragments, each thinking it starts at address zero, into one program where everything points at the right place. There are two times this can happen, and the distinction is central: link-time relocation is done once by the linker while building the executable, and load-time relocation is done by the dynamic linker each time the program starts, for the addresses that are only known once libraries are mapped at their actual load addresses. Position-independent code is designed to need very few load-time relocations, which is why it can be shared cheaply; a non-PIC binary that must be loaded at a fixed address needs none at runtime but cannot be relocated or shared as flexibly.