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 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 Relocation Entries. 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
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 executable or from
one of its dependencies.