SPRAB89A September 2011 – March 2014
When an object refers to a global symbol defined in another object, it is said to import that symbol, and the defining object is said to export it. Suppose two different objects define and export the same symbol. One of the definitions takes priority and preempts the other. Preemption enables dynamic linkage to behave identically to static linkage: the executable's definition preempts that of the library, so the library's instance is not linked in. In the dynamic linking case the library may already be loaded, and a definition in a shared instance may be needed by one client but not by another.
Preemption means that even though at static link time a symbol appears to be defined within the module, in fact it may be replaced by a different definition at dynamic link time. This has implications for the compiler, which must generate code as if the symbol were imported. For this reason preemption is expensive, even when it does not actually occur. The performance impact is discussed in Section 6.9. Linux uses a technique called import-as-own, discussed in Section 15.10, to alleviate the penalty for the executable.
The symbol visibility field in the ELF symbol table indicates a symbol's preemptability. Symbols marked as STV_HIDDEN or STV_INTERNAL are not exported (and therefore not preemptable). Symbols marked STV_PROTECTED are exported, but cannot be preempted. Symbols marked as STV_DEFAULT can be preempted.
Different platform and toolchain-specific conventions apply to which symbols can be preempted and how the programmer specifies visibility.