Relocation Symbol Lookup
The runtime linker is responsible for searching for
symbols that are required by objects at runtime. Typically, users
become familiar with the default search model that is applied to an
executable and its dependencies, and to the objects obtained
through
dlopen
(3C). However, more complex flavors of
symbol lookup can result because of the symbol attributes of an
object, or through specific binding requirements.
Two attributes of an object affect symbol lookup. The first attribute is the requesting object's symbol search scope. The second attribute is the symbol visibility offered by each object within the process.
These attributes can be applied as defaults at the time the object is
loaded. These attributes can also be supplied as specific modes to
dlopen
(3C). In some cases, these attributes can
be recorded within the object at the time the object is
built.
An object can define a world search scope, and/or a group search scope.
-
world
-
The object can search for symbols in any other global object within the process.
-
group
-
The object can search for symbols in any object of the same group. The dependency tree created from an object obtained with
dlopen
(3C), or from an object built using the link-editor's-B group
option, forms a unique group.
An object can define that any of the object's exported symbols are globally visible or locally visible.
-
global
-
The object's exported symbols can be referenced from any object that has world search scope.
-
local
-
The object's exported symbols can be referenced only from other objects that make up the same group.
The runtime symbol search can also be dictated by a
symbols visibility. Symbols assigned the
STV_SINGLETON
visibility are not affected
by any symbol search scope. All references to a singleton symbol are
bound to the first occurrence of a singleton definition within the
process. See ELF Symbol Visibility.
The simplest form of symbol lookup is outlined in the next section
Default Symbol Lookup. Typically, symbol attributes are exploited by
various forms of
dlopen
(3C). These scenarios are discussed in
Symbol Lookup.
An alternative model for symbol lookup is provided when a dynamic object employs direct bindings. This model directs the runtime linker to search for a symbol directly in the object that provided the symbol at link-edit time. See Direct Bindings.