Next: , Up: Foreign Linkage

4.1 Linkage-table

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*.

4.1.1 Differences to CMUCL

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.

4.1.2 Nitty Gritty Details

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.)

4.1.3 Porting Porting to new operating systems

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. Porting to new architectures

Write arch_write_linkage_table_jmp and arch_write_linkage_table_ref.


Define correct SB!VM:LINKAGE-TABLE-ENTRY-SIZE in src/compiler/target/parms.lisp.