Shared Objects as Filters

Shared objects can be defined to act as filters. This technique involves associating the interfaces that the filter provides with an alternative shared object. At runtime, the alternative shared object supplies one or more of the interfaces provided by the filter. This alternative shared object is referred to as a filtee . A filtee is built in the same manner as any shared object is built.

Filtering provides a mechanism of abstracting the compilation environment from the runtime environment. At link-edit time, a symbol reference that binds to a filter interface is resolved to the filters symbol definition. At runtime, a symbol reference that binds to a filter interface can be redirected to an alternative shared object.

Individual interfaces that are defined within a shared object can be defined as filters by using the mapfile FILTER or AUXILIARY attributes to the SYMBOL_SCOPE and SYMBOL_VERSION directives. Alternatively, a shared object can define all of the interfaces the shared object offers as filters by using the link-editor mapfile FILTER directive or the -F or -f command line options. These techniques are typically used individually, but can also be combined within the same shared object.

Three forms of filtering exist.

Standard filtering

This filtering requires only a symbol table entry for the interface being filtered. At runtime, the implementation of a filter symbol definition must be provided from a filtee.

Interfaces are defined to act as standard filters by using the link-editor's mapfile FILTER directive, or FILTER per-symbol attribute, or by using the link-editor's -F option. The mapfile keyword or command line option, is qualified with the name of one or more filtees that must supply the symbol definition at runtime.

A filtee that cannot be processed at runtime is skipped. A standard filter symbol that cannot be located within the filtee, also causes the filtee to be skipped. In both of these cases, the symbol definition provided by the filter is not used to satisfy this symbol lookup.

Weak filtering

Weak filtering is a variation of standard filtering. At runtime, weak filters are processed the same as standard filters. Weak filters differ from standard filters in how the link-editor processes weak filter dependencies when unused dependency processing is enabled with the -z discard-unused=dependencies option.

Typically, the link-editor resolves external symbols from libraries to the first library on the command line that offers a symbol definition. In the case of weak filters, such symbols are ignored if the filtee providing the same symbol is also present on the command line. Resolving such symbols directly to the filtee can allow unused dependency processing to eliminate the filter as a dependency, resulting in a simpler and more efficient object.

Interfaces are defined to act as weak filters by using the link-editor's mapfile FILTER directive, or FILTER per-symbol attribute. This mapfile keyword is qualified with the name of one or more filtees that must supply the symbol definition at runtime.

Auxiliary filtering

This filtering provides a similar mechanism to standard filtering, except the filter provides a fallback implementation corresponding to the auxiliary filter interfaces. At runtime, the implementation of the symbol definition can be provided from a filtee.

Interfaces are defined to act as auxiliary filters by using the link-editor's mapfile FILTER directive, or with the FILTER or AUXILIARY per-symbol attribute, or by using the link-editor's -f option. This mapfile keyword or option, is qualified with the name of one or more filtees that can supply the symbol definition at runtime.

A filtee that cannot be processed at runtime is skipped. An auxiliary filter symbol that cannot be located within the filtee, also causes the filtee to be skipped. In both of these cases, the symbol definition provided by the filter is used to satisfy this symbol lookup.