By default, programs are linked so that a reference to a symbol imported from a shared object is bound to that definition at load time. This is true even if the program, or another shared object required by the program, defines the same symbol.
| Runtime linker | A shared object that allows symbols to be rebound for appropriately linked programs |
You include the runtime linker in a program by linking the program with the -brtl option. This option has the following effects:
# autoload #! (foo.o)and adding the file as a member to the archive.
The runtime linker mimics the behavior of the ld command when static linking is used, except that only exported symbols can be used to resolve symbols. Even when runtime linking is used, the system loader must be able to load and resolve all symbol references in the main program and any module it depends on. Therefore, if a definition is removed from a module, and the main program has a reference to this definition, the program will not execute, even if another definition for the symbol exists in another module.
The runtime linker can rebind all references to symbols imported from another module. A reference to a symbol defined in the same module as the reference can only be rebound if the module was built with runtime linking enabled for that symbol.
Shared modules shipped with AIX Version 4.2 or later have runtime linking enabled for most exported variables. Runtime linking for functions is only enabled for functions called through a function pointer. For example, as shipped, calls to the malloc subroutine within shared object shr.o in /lib/libc.a cannot be rebound, even if a definition of malloc exists in the main program or another shared module. You can link most shipped shared modules to enable runtime linking for functions as well as variables by running the rtl_enable command.
The main program is loaded and resolved by the system loader in the usual way. If the executable program cannot be loaded for any reason, the exec() subroutine fails and the runtime linker is not invoked at all. If the main program loads successfully, control passes to the runtime linker, which rebinds symbols as described below. When the runtime linker completes, initialization routines are called, if appropriate, and then the main function is called.
The runtime linker processes modules in breadth-first search order, starting with the main executable and continuing with the direct dependents of the main executable, according to the order of dependent modules listed in each module's loader section. This order is also used when searching for the defining instance of a symbol. The "defining instance" of a symbol is usually the first instance of a symbol, but there are two exceptions. If the first instance of a symbol is an unresolved, deferred import, no defining instance exists. If the first instance is a BSS symbol (that is, with type XTY_CM, indicating an uninitialized variable), and there is another instance of the symbol that is neither a BSS symbol nor an unresolved, deferred import, the first such instance of the symbol is the defining instance.
The loader section of each module lists imported symbols, which are usually defined in another specified module, and exported symbols, which are usually defined in the module itself. A symbol that is imported and exported is called a "passed-through'' import. Such a symbol appears to be defined in one module, although it is actually defined in another module.
Symbols can also be marked as "deferred imports." References to deferred import symbols are never rebound by the runtime linker. Resolution of these symbols must be performed by the system loader, either by calling loadbind() or by loading a new module explicitly with load() or dlopen().
References to imported symbols (other than deferred imports) can always be rebound. The system loader will have already resolved most imports. References to each imported symbol are rebound to the symbol's defining instance. If no defining instance exists, an error message will be printed to standard error. In addition, if the typechecking hash string of an imported symbol does not match the hash string of the defining symbol, an error message is printed.
References to exported symbols are also rebound to their defining instances, as long as the references appear in the relocation table of the loader section. (Passed-through imports are processed along with other imports, as described above.) Depending on how the module was linked, some references to exported symbols are bound at link time and cannot be rebound. Since exported symbols are defined in the exporting module, a defining instance of the symbol will always exist, unless the first instance is a deferred import, so errors are unlikely, but still possible, when rebinding exported symbols. As with imports, errors are printed if the typechecking hash strings do not match when a symbol is rebound.
Whenever a symbol is rebound, a dependency is added from the module using the symbol to the module defining the symbol. This dependency prevents modules from being removed from the address space prematurely. This is important when a module loaded by the dlopen subroutine defines a symbol that is still being used when an attempt is made to unload the module with the dlclose subroutine.
The loader section symbol table does not contain any information about the alignment or length of symbols. Thus, no errors are detected when symbols are rebound to instances that are too short or improperly aligned. Execution errors may occur in this case.
Once all modules have been processed, the runtime linker calls the exit subroutine if any runtime linking errors occurred, passing an exit code of 144 (0x90). Otherwise, execution continues by calling initialization routines or main().
To create a shared object enabled for runtime linking, you link with the -G flag. When this flag is used, the following actions take place:
Using the -berok option, implied by the -G flag, can mask errors that could be detected at link time. If you intend to define all referenced symbols when linking a module, you should use the -bernotok option after the -G flag. This causes errors to be reported for undefined symbols.
The ld command, the rtl_enable command.
The dlclose subroutine, dlopen subroutine, exec subroutine, exit subroutine, and malloc subroutine.