Next: Lazy Alien Resolution, Up: Foreign Linkage
Linkage-table allows saving cores with foreign code loaded, and is also utilized to allow references to as-of-yet unknown aliens. See Lazy Alien Resolution.
The SBCL implementation is somewhat simplified from the CMUCL one by
Timothy Moore, but the basic idea and mechanism remain identical:
instead of having addresses from dlsym(3) in the core, we have
addresses to an mmapped memory area (LINKAGE_TABLE_SPACE) that
is initialized at startup to contain jumps & references to the correct
addresses, based on information stored on the lisp side in
*LINKAGE-INFO*.
CMUCL does lazy linkage for code, keeps all foreign addresses in the
linkage-table, and handles the initialization from C. We do eager
linkage for everything, maintain a separate
*STATIC-FOREIGN-SYMBOLS* just like on non-linkage-table ports
(this allows more code sharing between ports, makes thread-safety
easier to achieve, and cuts one jump's worth of overhead from stuff
like closure_tramp), and do the initialization from lisp.
Symbols in *STATIC-FOREIGN-SYMBOLS* are handled the old
fashioned way: linkage-table is only used for symbols resolved with
dlsym(3).
On system startup FOREIGN-REINIT iterates through the
*LINKAGE-INFO*, which is a hash-table mapping dynamic foreign
names to LINKAGE-INFO structures, and calls
arch_write_linkage_table_jmp/ref to write the
appropriate entries to the linkage-table.
When a foreign symbol is referred to, it is first looked for in the
*STATIC-FOREIGN-SYMBOLS*. If not found,
ENSURE-FOREIGN-LINKAGE is called, which looks for the
corresponding entry in *LINKAGE-INFO*, creating one and writing
the appropriate entry in the linkage table if necessary.
FOREIGN-SYMBOL-ADDRESS and FOREIGN-SYMBOL-SAP take an
optional datap argument, used to indicate that the symbol refers to a
variable. In similar fashion there is a new kind of fixup and a new
VOP: :FOREIGN-DATAREF and FOREIGN-SYMBOL-DATAREF-SAP.
The DATAP argument is automagically provided by the alien
interface for normal definitions, but is really needed only for
dynamic foreign variables. For those it indicates the need for the
indirection either within a conditional branch in
FOREIGN-SYMBOL-SAP, or via :FOREIGN-DATAREF fixup and
FOREIGN-SYMBOL-DATAREF-SAP VOP: "this address holds the
address of the foreign variable, not the variable itself". Within SBCL
itself (in the fixups manifest in various VOPs) this fixup type is
never used, as all foreign symbols used internally are static.
One thing worth noting is that FOREIGN-SYMBOL-SAP and friends
now have the potential side-effect of entering information in
*LINKAGE-INFO* and the linkage-table proper. If the usage case
is about checking if the symbol is available use
FIND-FOREIGN-SYMBOL-ADDRESS, which is side-effect free. (This
is used by SB-POSIX.)
Find a memory area for the linkage-table, and add it for the OS in
src/compiler/target/parms.lisp by defining
SB!VM:LINKAGE-TABLE-SPACE-START and
SB!VM:LINKAGE-TABLE-SPACE-END. See existing ports and CMUCL for
examples.
Write arch_write_linkage_table_jmp and arch_write_linkage_table_ref.
Write FOREIGN-SYMBOL-DATAREF VOP.
Define correct SB!VM:LINKAGE-TABLE-ENTRY-SIZE in
src/compiler/target/parms.lisp.