@xref{Lazy Alien Resolution}.
The SBCL implementation is somewhat simplified from the CMUCL one by
-Timothy Moore, but the basic idea and mechanism remains identical:
+Timothy Moore, but the basic idea and mechanism remain identical:
instead of having addresses from @code{dlsym(3)} in the core, we have
addresses to an mmapped memory area (@code{LINKAGE_TABLE_SPACE}) that
is initialized at startup to contain jumps & references to the correct
corresponding entry in @code{*LINKAGE-INFO*}, creating one and writing
the appropriate entry in the linkage table if necessary.
-@code{FOREIGN-SYMBOL-ADDRESS} and
-@code{FOREIGN-SYMBOL-ADDRESS-AS-INTEGER} 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:
-@code{:FOREIGN-DATAREF} and @code{FOREIGN-SYMBOL-DATAREF-ADDRESS}. The
-@code{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 @code{FOREIGN-SYMBOL-ADDRESS}, or via
-@code{:FOREIGN-DATAREF} fixup and
-@code{FOREIGN-SYMBOL-DATAREF-ADDRESS} VOP: "this address holds the
+@code{FOREIGN-SYMBOL-ADDRESS} and @code{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: @code{:FOREIGN-DATAREF} and @code{FOREIGN-SYMBOL-DATAREF-SAP}.
+
+The @code{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
+@code{FOREIGN-SYMBOL-SAP}, or via @code{:FOREIGN-DATAREF} fixup and
+@code{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 @code{FOREIGN-SYMBOL-ADDRESS} and
-friends now have the potential side-effect of entering information in
-@code{*LINKAGE-INFO*} and the linkage-table proper: hence it's important to
-use the correct datap argument even if calling these just to "check if
-it's there" (like SB-POSIX does).
+One thing worth noting is that @code{FOREIGN-SYMBOL-SAP} and friends
+now have the potential side-effect of entering information in
+@code{*LINKAGE-INFO*} and the linkage-table proper. If the usage case
+is about checking if the symbol is available use
+@code{FIND-FOREIGN-SYMBOL-ADDRESS}, which is side-effect free. (This
+is used by SB-POSIX.)
@subsection Porting
@code{SB!VM:LINKAGE-TABLE-SPACE-END}. See existing ports and CMUCL for
examples.
-@subsubsection Porting to new architextures
+@subsubsection Porting to new architectures
Write @code{arch_write_linkage_table_jmp} and @code{arch_write_linkage_table_ref}.
before the shared object containing the alien in question has been
loaded.
-This is handled by @code{GET-DYNAMIC-FOREIGN-SYMBOL-ADDRESS}, which
+This is handled by @code{ENSURE-DYNAMIC-FOREIGN-SYMBOL-ADDRESS}, which
first tries to resolve the address in the loaded shared objects, but
failing that records the alien as undefined and returns the address of
a read/write/execute protected guard page for variables, and address
saves the arguments from the C-call according to the alien-fun-type of
the callback, and calls #'ENTER-ALIEN-CALLBACK with the index
-indentifying the callback, a pointer to the arguments copied on the
+identifying the callback, a pointer to the arguments copied on the
stack and a pointer to return value storage. When control returns to
the wrapper it returns the value to C. There is one assembler wrapper
per callback.[1] The SAP to the wrapper code vector is what is passed
projects / sbcl.git / blobdiff