dld.sl(5)

NAME

dld.sl − dynamic loader

DESCRIPTION

The /usr/lib/dld.sl program is the dynamic loader. In programs that use shared libraries, /usr/lib/dld.sl is invoked automatically at startup time by the startup file crt0.o. Identical copies of crt0.o are kept in both /opt/langtools/lib/ and /usr/ccs/lib/ directories. The dynamic loader is, itself, a shared library, although it defines no symbols for use by user programs.

Shared Libraries

Shared libraries are executable files created with the -b option to ld (see ld(1)). They must contain position-independent code (PIC) that can be mapped anywhere in the address space of a process and executed with minimal relocation. PIC can use PC -relative addressing modes and/or linkage tables. It can be generated with the +z/+Z options to the compilers. See the +help option to ld(1) or the Programming on HP-UX manual for details on writing PIC in assembly language.

Incomplete Executables

An executable program linked with one or more shared libraries is called an incomplete executable.

When creating an executable (a.out) file from object files and libraries, the linker does not copy text (code) or data from the shared library into the output file. Instead, the dynamic loader maps the library into the address space of the process at run time. The linker binds all program references to shared library routines and data to entries in a linkage table, and relies on the dynamic loader to fill in the linkage table entries once the libraries have been mapped. This linkage table serves as a jump table for function calls.

In previous releases, shared library data items referenced by the program were copied into the program executable file so that the data references could be resolved statically. Beginning with the Series 700/800 10.0 release, references to shared library data from the a.out are included in a linkage table and are resolved at run time.

Loading

An incomplete executable contains a list of path names of the shared libraries searched at link time. At run time, the dynamic loader attaches to the process all shared libraries that were linked with the program. The dynamic loader will attempt to load each library from the same directory in which it was found at link time. It is possible to change the shared library run time search path by specifying a dynamic path list. There are two ways to specify a dynamic path list :

• by storing a directory path list in the executable using the +b path_list option to ld

• by linking the executable with ld option +s, enabling the executable to use the path list defined by the SHLIB_PATH environment variable at run time

The path list is a list of one or more path names separated by colons (:). The dynamic path list will work only for libraries specified with the -l option to ld. However, it can be enabled for libraries specified with a full path name using the -l option to chatr (see chatr(1)). If both +s and +b are used, their relative order on the command line indicates which path list will be searched first. See the +help option to ld(1) or the Programming on HP-UX manual for more details.

The text segment of a library is shared among all processes that use it. The data and bss segments are shared on a page-by-page basis. When a process first accesses (reads or writes) a data or bss page, a copy of that page is made for the process.

Binding

The dynamic loader also resolves symbolic references between the executable and libraries. By default, function calls are trapped via the linkage table and bound on first reference. References to data symbols and other absolute address references cannot be trapped. They are bound on the first resolution of a function call that could potentially reference the object.

If the -B immediate option to ld is used, the loader binds all necessary references at startup time. This increases the startup cost of a program, but ensures that no more binding operations will be required later. Thus, better real-time response may result, and the risk of a later abort due to unresolved externals is eliminated.

The fastbind tool can be used to improve the start-up time of programs that use shared libraries (incomplete executables). The fastbind tool performs analysis on the shared library routines and data used to bind the symbols and stores this information in the executable file. The dynamic loader will notice that this information is available, and it will use this fastbind information to bind the symbols instead of the standard search method. For more details refer to fastbind(1) and the +help option to ld(1) or the Programming on HP-UX manual.

Version Control

Since code from a shared library is mapped at run time from a separate shared library file, modifications to a shared library may alter the behavior of existing executables. In some cases, this may cause programs to operate incorrectly. Two means of version control is provided to solve this problem.

1. Intra-Library Versioning

Whenever an incompatible change is made to a library interface, both versions of the affected module or modules are included in the library. A mark indicating the date (month/year) the change was made is recorded in the new module via the pragma HP_SHLIB_VERSION in C, or the compiler directive SHLIB_VERSION in Fortran and Pascal. This date applies to all symbols defined within the module. A high water mark giving the date of the latest incompatible change is recorded in the shared library, and the high water mark for each library linked with the program is recorded in the incomplete executable file. At run time, the dynamic loader checks the high water mark of each library and loads the library only if it is at least as new as the high water mark recorded at link time. When binding symbolic references, the loader chooses the latest version of a symbol that is not later than the high water mark recorded at link time. These two checks help ensure that the version of each library interface used at run time is the same as was expected at link time. Intra-library versioning may be removed in a future release.

2. Library-level Versioning

The second way for users to version their libraries is by using a new naming convention, libname.n where n is a numeral that is incremented with every new release of the library. When using the new naming scheme, users must specify an internal name for the shared library by using the +h internal_name option to ld when building the shared library. This internal name is recorded in each incomplete executable or shared library that links with the shared library.

At run time, the loader will look at the library list recorded in the incomplete executable file or shared library. For each library in the list that was not an internal name, the dynamic loader will look for a .0 version of the library (e.g. libname.0 ) to load. If it does not find this version, it will look for the library name that is recorded in the list.

Explicit Loading And Binding

The duties of the dynamic loader as described above are all performed automatically, although they can be controlled somewhat by appropriate options to ld. The dynamic loader can also be accessed programmatically. The reserved variable __dld_loc, which is defined in crt0.o, points to a jump table within the dynamic loader. The routines described under shl_load(3X) provide a portable interface that allows the programmer to explicitly attach a shared library to the process at run time, to calculate the addresses of symbols defined within shared libraries, and to detach the library when done.

DIAGNOSTICS

If the dynamic loader is not present, or cannot be invoked by the process for any reason, an error message is printed to standard error and the process terminates with a non-zero exit code.

Normally, the operation of the dynamic loader is visible only when there is a fatal error of some kind. In these cases, an error message is printed to standard error and a SIGABRT signal is sent to the process. These errors fall into two basic categories: errors in attaching a shared library, and errors in binding symbols. The former can occur only at process startup time but the latter can occur at any time during process execution unless the -B immediate option is used with ld. Possible errors that can occur while attaching a shared library include library not present, library not executable, library corrupt, high water mark too low, or insufficient room in the address space for the library. Possible errors that can occur while binding symbols include symbol not found (unresolved external), or library corrupt.

When using the explicit load facilities of the dynamic loader, these types of errors are not considered fatal. Consult shl_load(3X) for information on error handling.

WARNINGS

The startup cost of the dynamic loader is significant, even with deferred binding, and can cause severe performance degradation in processes dominated by startup costs (such as simple “hello world” programs). In addition, position-independent code is usually slower than normal code, so performance of a program may be adversely affected by the presence of PIC in shared libraries. However, the advantages of decreased disk space usage and decreased memory requirements for executables should outweigh these concerns in most cases.

There are rare cases where the behavior of a program differs when using shared libraries as opposed to archive libraries. This happens primarily when relying on undocumented and unsupported features of the compilers, assembler, and linker. See the +help option to ld(1) or the Programming on HP-UX manual for more details.

The library developer is entirely responsible for version control and must be thorough in identifying incompatible changes to library interfaces. Otherwise, programs may malfunction unexpectedly with later versions of the library. There is little an application user can do if version control is not handled properly by the library developer. The application developer can usually resolve problems by modifying the source code to use the new interfaces then recompiling and relinking against the new libraries.

By default, most warnings are not reported by the dynamic loader. If you wish to see all of the messages, set the environment variable _HP_DLDOPTS to contain one or more options. The following options are supported:

-warnings Display additional dynamic loader warning messages. Some of these include:

• Symbols of the same name but different types, such as CODE and DATA. See the WARNINGS section in ld(1) for more details on this warning.

• Using certain flags or routines described in shl_load(3X).

-fbverbose See fastbind(1).

-nofastbind See fastbind(1).

AUTHOR

The /usr/lib/dld.sl program was developed by HP.

Museum

Related Articles