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, orFILTER
per-symbol attribute, or by using the link-editor's-F
option. Themapfile
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, orFILTER
per-symbol attribute. Thismapfile
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 theFILTER
orAUXILIARY
per-symbol attribute, or by using the link-editor's-f
option. Thismapfile
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.