After the runtime linker has loaded all the dependencies required by an application, the linker processes each object and performs all necessary relocations.
During the link-editing of an object, any relocation information supplied with the input relocatable objects is applied to the output file. However, when creating a dynamic executable or shared object, many of the relocations cannot be completed at link-edit time. These relocations require logical addresses that are known only when the objects are loaded into memory. In these cases, the link-editor generates new relocation records as part of the output file image. The runtime linker must then process these new relocation records.
For a more detailed description of the many relocation types, see Relocations. Two basic types of relocation exist.
The relocation records for an object can be displayed by using elfdump(1). In the following example, the file libbar.so.1 contains two relocation records that indicate that the global offset table, or .got section, must be updated.
$ elfdump -r libbar.so.1
Relocation Section: .rel.got:
type offset section symbol
R_SPARC_RELATIVE 0x10438 .rel.got
R_SPARC_GLOB_DAT 0x1043c .rel.got foo
The first relocation is a simple relative relocation that can be seen from the relocation type and that no symbol is referenced. This relocation needs to use the base address at which the object is loaded into memory to update the associated .got offset.
The second relocation requires the address of the symbol foo. To complete this relocation, the runtime linker must locate this symbol from either the dynamic executable or from one of its dependencies.