Linker and Libraries Guide

Establishing a Namespace

When the runtime linker binds a dynamic executable with its dependencies, a linked list of link-maps is generated to describe the process. The link-map structure describes each object within the process. The link-map structure is defined in /usr/include/sys/link.h. The symbol search mechanism required to bind objects of an application traverses this list of link-maps. This link-map list is said to provide the namespace for process symbol resolution.

The runtime linker is also described by a link-map. This link-map is maintained on a different list from the list of application objects. The runtime linker therefore resides in its own unique name space, which prevents the application from binding to any services within the runtime linker. An application can only call upon the public services of the runtime linker by the filter libc.so.1, or libdl.so.1.

The rtld-audit interface employs its own link-map list on which the audit libraries are maintained. The audit libraries are thus isolated from the symbol binding requirements of the application. Inspection of the application link-map list is possible with dlmopen(3C). When used with the RTLD_NOLOAD flag, dlmopen(3C) allows the audit library to query an object's existence without causing its loading.

Two identifiers are defined in /usr/include/link.h to define the application and runtime linker link-map lists.

#define LM_ID_BASE      0     /* application link-map list */
#define LM_ID_LDSO      1     /* runtime linker link-map list */

Every rtld-audit support library is assigned a unique new link-map identifier.