Oracle® Solaris 11.2 Linkers and Libraries Guide

Exit Print View

Updated: July 2014

Relocation Processing

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.

  • Non-symbolic relocations

  • Symbolic relocations

The relocation records for an object can be displayed by using elfdump(1). In the following example, the file contains two relocation records that indicate that the global offset table, or .got section, must be updated.

$ elfdump -r

Relocation Section:
    type                      offset             section       symbol
  R_SPARC_RELATIVE           0x10438   
  R_SPARC_GLOB_DAT           0x1043c         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.