Default Symbol Lookup Model

For each object added by dlopen(3DL) the runtime linker will first look for the symbol in the dynamic executable, and then look in each of the objects provided during the initialization of the process. However, 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.

For example, take the dynamic executable prog, and the shared object B.so.1, each of which has 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, it might be easier to 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, but not to 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 assigned the dynamic executable and all the dependencies loaded with it, and 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 thus maintain associations between objects based on their introduction into the process address space, and on any dependency relationships between the objects. Assigning the objects associated with a given dlopen(3DL) 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, if the shared object D.so.1 has the following dependency:

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

and the prog application was to dlopen(3DL) this shared object in addition to the shared object B.so.1, then diagrammatically the symbol lookup relationship between the objects can be represented as shown in the following figure:

Figure 3-2 Multiple dlopen() Requests

If 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, then 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.

For example, see the shared objects O.so.1 and P.so.1, which 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, it will be assigned to both of the groups that are associated with the two dlopen(3DL) calls. Diagrammatically this can be represented as shown in the following figure:

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

The result is that Z.so.1 will be available for both O.so.1 and P.so.1 to look up symbols, but 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.