Linker and Libraries Guide

Relocation Processing

As described in Chapter 3, Runtime Linker, after locating and loading any objects, the runtime linker must process each object and perform any necessary relocations. Any objects brought into the process's address space with dlopen(3DL) must also be relocated in the same manner.

For simple applications this process is straightforward. However, for users who have more complex applications with many dlopen(3DL) calls involving many objects, possibly with common dependencies, this process can be quite important.

Relocations can be categorized according to when they occur. The default behavior of the runtime linker is to process all immediate reference relocations at initialization and all lazy references during process execution, a mechanism commonly referred to as lazy binding.

This same mechanism is applied to any objects added with dlopen(3DL) when the mode is defined as RTLD_LAZY. An alternative is to require all relocations of an object to be performed immediately when the object is added. You can use a mode of RTLD_NOW, or record this requirement in the object when it is built using the link-editor's -z now option. This relocation requirement is propagated to any dependencies of the object being opened.

Relocations can also be categorized into non-symbolic and symbolic. The remainder of this section covers issues regarding symbolic relocations, regardless of when these relocations occur, with a focus on some of the subtleties of symbol lookup.

Symbol Lookup

If an object acquired by dlopen(3DL) refers to a global symbol, the runtime linker must locate this symbol from the pool of objects that make up the process. In the absence of direct binding, a default symbol search model is applied to objects obtained by dlopen(3DL). However, the mode of a dlopen(3DL), combined with the attributes of the objects that make up the process, provide for alternative symbol search models.

Objects that required direct binding, although maintaining all the attributes described later, search for symbols directly in the associated dependency. See "Direct Binding".

Two attributes of an object affect symbol lookup. The first is the requesting object's symbol search scope, and the second is the symbol visibility offered by each object within the process. An object's search scope can be:

world: The object can look in any other global object within the process.
group: The object can look only in an object of the same group. The dependency tree created from an object obtained with dlopen(3DL), or from an object built using the link-editor's -B group option, forms a unique group.

The visibility of a symbol from an object can be:

global: The object's symbols can be referenced from any object having world search scope.
local: The object's symbols can be referenced only from other objects that make up the same group.

By default, objects obtained with dlopen(3DL) are assigned world symbol search scope, and local symbol visibility. The section, "Default Symbol Lookup Model", uses this default model to illustrate typical object group interactions. The sections "Defining a Global Object", "Isolating a Group", and "Object Hierarchies" show examples of using dlopen(3DL) modes and file attributes to extend the default symbol lookup model.

Default Symbol Lookup Model

For each object added by dlopen(3DL) the runtime linker will first look for the symbol in the dynamic executable. The runtime linker will then look in each of the objects provided during the initialization of the process. If the symbol is still not found, the runtime linker will continue the search, looking in the object acquired through the dlopen(3DL) and in any of its dependencies.

In the following example, the dynamic executable prog and the shared object B.so.1 each have the following (simplified) dependencies:

$ ldd prog
        A.so.1 =>        ./A.so.1
$ ldd B.so.1
        C.so.1 =>        ./C.so.1

If prog acquires the shared object B.so.1 by dlopen(3DL), then any symbol required to relocate the shared objects B.so.1 and C.so.1 will first be looked for in prog, followed by A.so.1, followed by B.so.1, and finally in C.so.1. In this simple case, think of the shared objects acquired through the dlopen(3DL) as if they had been added to the end of the original link-edit of the application. For example, the objects referenced in the previous listing can be expressed diagrammatically as shown in the following figure.

Figure 3-1 A Single dlopen() Request

Any symbol lookup required by the objects acquired from the dlopen(3DL), shown as shaded blocks, will proceed from the dynamic executable prog through to the final shared object C.so.1.

This symbol lookup is established by the attributes assigned to the objects as they were loaded. Recall that the dynamic executable and all the dependencies loaded with it are assigned global symbol visibility, and that the new objects are assigned world symbol search scope. Therefore, the new objects are able to look for symbols in the original objects. The new objects also form a unique group in which each object has local symbol visibility. Therefore, each object within the group can look for symbols within the other group members.

These new objects do not affect the normal symbol lookup required by either the application or its initial object dependencies. For example, if A.so.1 requires a function relocation after the above dlopen(3DL) has occurred, the runtime linker's normal search for the relocation symbol will be to look in prog and then A.so.1. The runtime linker will not follow through and look in B.so.1 or C.so.1.

This symbol lookup is again a result of the attributes assigned to the objects as they were loaded. The world symbol search scope is assigned to the dynamic executable and all the dependencies loaded with it. This scope does not allow them to look for symbols in the new objects that only offer local symbol visibility.

These symbol search and symbol visibility attributes maintain associations between objects based on their introduction into the process address space, and on any dependency relationship between the objects. Assigning the objects associated with a given dlopen(3DL) to a unique group ensures that only objects associated with the same dlopen(3DL) are allowed to look up symbols within themselves and their related dependencies.

This concept of defining associations between objects becomes more clear in applications that carry out more than one dlopen(3DL). For example, suppose the shared object D.so.1 has the following dependency:

$ ldd D.so.1
        E.so.1 =>         ./E.so.1

and the prog application used dlopen(3DL) to load this shared object in addition to the shared object B.so.1. The following figure illustrates the symbol lookup releationship between the objects.

Figure 3-2 Multiple dlopen() Requests

Suppose that both B.so.1 and D.so.1 contain a definition for the symbol foo, and both C.so.1 and E.so.1 contain a relocation that requires this symbol. Because of the association of objects to a unique group, C.so.1 will be bound to the definition in B.so.1, and E.so.1 will be bound to the definition in D.so.1. This mechanism is intended to provide the most intuitive binding of objects obtained from multiple calls to dlopen(3DL).

When objects are used in the scenarios that have so far been described, the order in which each dlopen(3DL) occurs has no effect on the resulting symbol binding. However, when objects have common dependencies, the resultant bindings can be affected by the order in which the dlopen(3DL) calls are made.

In the following example, the shared objects O.so.1 and P.so.1 have the same common dependency.

$ ldd O.so.1 
        Z.so.1 =>        ./Z.so.1
$ ldd P.so.1 
        Z.so.1 =>        ./Z.so.1

In this example, the prog application will dlopen(3DL) each of these shared objects. Because the shared object Z.so.1 is a common dependency of both O.so.1 and P.so.1, Z.so.1 will be assigned to both of the groups that are associated with the two dlopen(3DL) calls. This relationship is shown in the following figure.

Figure 3-3 Multiple dlopen() Requests With A Common Dependency

Z.so.1 will be available for both O.so.1 and P.so.1 to look up symbols. More importantly, as far as dlopen(3DL) ordering is concerned, Z.so.1 will also be able to look up symbols in both O.so.1 and P.so.1.

Therefore, if both O.so.1 and P.so.1 contain a definition for the symbol foo, which is required for a Z.so.1 relocation, the actual binding that occurs is unpredictable because it will be affected by the order of the dlopen(3DL) calls. If the functionality of symbol foo differs between the two shared objects in which it is defined, the overall outcome of executing code within Z.so.1 might vary depending on the application's dlopen(3DL) ordering.

Defining a Global Object

The default assignment of local symbol visibility to the objects obtained by a dlopen(3DL) can be promoted to global by augmenting the mode argument with the RTLD_GLOBAL flag. Under this mode, any objects obtained through a dlopen(3DL) can be used by any other objects with world symbol search scope to locate symbols.

In addition, any object obtained by dlopen(3DL) with the RTLD_GLOBAL flag will be available for symbol lookup using dlopen() with a path name whose value is 0.

Note - If a member of a group having local symbol visibility is referenced by another group requiring global symbol visibility, the object's visibility will become a concatenation of both local and global. This promotion of attributes will remain even if the global group reference is later removed.

Isolating a Group

The default assignment of world symbol search scope to the objects obtained by a dlopen(3DL) can be reduced to group by augmenting the mode argument with the RTLD_GROUP flag. Under this mode, any objects obtained through a dlopen(3DL) will only be allowed to look for symbols within their own group.

Using the link-editor's -B group option, you can assign the group symbol search scope to objects when they are built.

Note - If a member of a group, having group search capability, is referenced by another group requiring world search capability, the object's search capability will become a concatenation of both group and world. This promotion of attributes will remain even if the world group reference is later removed.

Object Hierarchies

If an initial object, obtained from a dlopen(3DL), was to use dlopen(3DL) to open a secondary object, both objects would be assigned to a unique group. This situation can prevent either object from locating symbols from one another.

In some implementations the initial object has to export symbols for the relocation of the secondary object. This requirement can be satisfied by one of two mechanisms:

Making the initial object an explicit dependency of the second object
Use the RTLD_PARENT mode flag to dlopen(3DL) the secondary object

If the initial object is an explicit dependency of the secondary object, the initial object will also be assigned to the secondary objects' group. The initial object therefore will be able to provide symbols for the secondary objects' relocation.

If many objects can use dlopen(3DL) to open the secondary object, and each of these initial objects must export the same symbols to satisfy the secondary objects' relocation, then the secondary object cannot be assigned an explicit dependency. In this case, the dlopen(3DL) mode of the secondary object can be augmented with the RTLD_PARENT flag. This flag causes the propagation of the secondary objects' group to the initial object in the same manner as an explicit dependency would do.

There is one small difference between these two techniques. If you specify an explicit dependency, the dependency itself becomes part of the secondary objects' dlopen(3DL) dependency tree, and thus becomes available for symbol lookup with dlsym(3DL). If you obtain the secondary object with RTLD_PARENT, the initial object does not become available for symbol lookup with dlsym(3DL).

When a secondary object is obtained by dlopen(3DL) from an initial object with global symbol visibility, the RTLD_PARENT mode is both redundant and harmless. This case commonly occurs when dlopen(3DL) is called from an application or from one of the dependencies of the application.

Obtaining New Symbols

A process can obtain the address of a specific symbol using dlsym(3DL). This function takes a handle and a symbol name, and returns the address of the symbol to the caller. The handle directs the search for the symbol in the following manner:

The handle returned from a dlopen(3DL) of a named object enables symbols to be obtained from that object's dependency tree.
The handle returned from a dlopen(3DL) of a path name whose value is 0 enables symbols to be obtained from the dynamic executable, from any of its initialization dependencies, or from any object obtained by a dlopen(3DL) with the RTLD_GLOBAL mode.
The special handle RTLD_DEFAULT enables symbols to be obtained from the dynamic executable, from any of its initialization dependencies, or from any object obtained by a dlopen(3DL) that belongs to the same group as the caller.
The special handle RTLD_NEXT enables symbols to be obtained from the next associated object.

The first example is probably the most common. An application will add additional objects to its address space and use dlsym(3DL) to locate function or data symbols. The application then uses these symbols to call upon services provided in these new objects. For example, suppose the file main.c contains the following code:

#include    <stdio.h>
#include    <dlfcn.h>
 
main()
{
        void *  handle;
        int *   dptr, (* fptr)();
 
        if ((handle = dlopen("foo.so.1", RTLD_LAZY)) == NULL) {
                (void) printf("dlopen: %s\n", dlerror());
                exit (1);
        }
 
        if (((fptr = (int (*)())dlsym(handle, "foo")) == NULL) ||
            ((dptr = (int *)dlsym(handle, "bar")) == NULL)) {
                (void) printf("dlsym: %s\n", dlerror());
                exit (1);
        }
 
        return ((*fptr)(*dptr));
}


3. Runtime Linker Runtime Linking Programming Interface Loading Additional Objects