-;;;; support for dynamically loading foreign object files and
-;;;; resolving symbols therein
+;;;; Foreign symbol linkage
;;;; This software is part of the SBCL system. See the README file for
;;;; more information.
;;;; provided with absolutely no warranty. See the COPYING and CREDITS
;;;; files for more information.
-(in-package "SB-ALIEN") ; (SB-ALIEN, not SB!ALIEN, since we're in warm load.)
-
-(defun pick-temporary-file-name (&optional
- ;; KLUDGE: There are various security
- ;; nastyisms associated with easily
- ;; guessable temporary file names,
- ;; and we haven't done anything to
- ;; work around them here. -- pointed
- ;; out by Dan Barlow on sbcl-devel
- ;; 20000702
- (base "/tmp/sbcl-tmp-~D~C"))
- (let ((code (char-code #\A)))
- (loop
- (let ((name (format nil base (sb-unix:unix-getpid) (code-char code))))
- (multiple-value-bind (fd errno)
- (sb-unix:unix-open name
- (logior sb-unix:o_wronly
- sb-unix:o_creat
- sb-unix:o_excl)
- #o666)
- (cond ((not (null fd))
- (sb-unix:unix-close fd)
- (return name))
- ((not (= errno sb-unix:eexist))
- (simple-file-perror "couldn't create temporary file ~S"
- name
- errno))
- ;; KLUDGE: depends on ASCII character ordering -- WHN 20000128
- ((= code (char-code #\Z))
- (setf code (char-code #\a)))
- ((= code (char-code #\z))
- (return nil))
- (t
- (incf code))))))))
-
-
-;;; On any OS where we don't support foreign object file loading, any
-;;; query of a foreign symbol value is answered with "no definition
-;;; known", i.e. NIL.
-;;;
-;;; (On any OS which *does* support foreign object file loading, this
-;;; placeholder implementation is overwritten by a subsequent real
-;;; implementation.)
-;;;
-;;; You may want to use SB-SYS:FOREIGN-SYMBOL-ADDRESS instead of
-;;; calling this directly; see code/target-load.lisp.
-(defun get-dynamic-foreign-symbol-address (symbol)
- (declare (type simple-string symbol) (ignore symbol))
- nil)
-
-;;; dlsym()-based implementation of GET-DYNAMIC-FOREIGN-SYMBOL-ADDRESS
-;;; and functions (e.g. LOAD-FOREIGN) which affect it. This should
-;;; work on any ELF system with dlopen(3) and dlsym(3)
-;;; It also works on OpenBSD, which isn't ELF, but is otherwise modern
-;;; enough to have a fairly well working dlopen/dlsym implementation.
-#-(or linux FreeBSD OpenBSD)
-(macrolet ((define-unsupported-fun (fun-name)
- `(defun ,fun-name (&rest rest)
- "unsupported on this system"
- (declare (ignore rest))
- (error 'unsupported-operator :name ',fun-name))))
- (define-unsupported-fun load-1-foreign)
- (define-unsupported-fun load-foreign))
-#+(or linux FreeBSD OpenBSD)
-(progn
-
-;;; flags for dlopen()
-(defconstant rtld-lazy 1) ; lazy function call binding?
-(defconstant rtld-now 2) ; immediate function call binding?
-(defconstant rtld-global #x100) ; symbols of loaded obj file
- ; (and its dependencies) made
- ; visible (as though the
- ; obj file were linked directly
- ; into the program)?
-
-;;; a list of handles returned from dlopen(3) (or possibly some
-;;; bogus value temporarily during initialization)
-(defvar *handles-from-dlopen* nil)
-
-;;; Dynamically loaded stuff isn't there upon restoring from a save.
-;;; Clearing the variable this way was originally done primarily for
-;;; Irix, which resolves tzname at runtime, resulting in
-;;; *HANDLES-FROM-DLOPEN* (which was then called *TABLES-FROM-DLOPEN*)
-;;; being set in the saved core image, resulting in havoc upon
-;;; restart; but it seems harmless and tidy for other OSes too.
-;;;
-;;; Of course, it can be inconvenient that dynamically loaded stuff
-;;; goes away when we save and restore. However,
-;;; (1) trying to avoid it by system programming here could open a
-;;; huge can of worms, since e.g. now we would need to worry about
-;;; libraries possibly being in different locations (file locations
-;;; or memory locations) at restore time than at save time; and
-;;; (2) by the time the application programmer is so deep into the
-;;; the use of hard core extension features as to be doing
-;;; dynamic loading of foreign files and saving/restoring cores,
-;;; he probably has the sophistication to write his own after-save
-;;; code to reload the libraries without much difficulty.
-
-;;; dan 2001.05.10 suspects that objection (1) is bogus for
-;;; dlsym()-enabled systems
-
-(push (lambda () (setq *handles-from-dlopen* nil))
- *after-save-initializations*)
-
-(defvar *dso-linker* "/usr/bin/ld")
-(defvar *dso-linker-options* '("-shared" "-o"))
-
-
-(sb-alien:define-alien-routine dlopen system-area-pointer
- (file sb-alien:c-string) (mode sb-alien:int))
-(sb-alien:define-alien-routine dlsym system-area-pointer
- (lib system-area-pointer)
- (name sb-alien:c-string))
-(sb-alien:define-alien-routine dlerror sb-alien:c-string)
-
-;;; Ensure that we've opened our own binary so we can dynamically resolve
-;;; symbols in the C runtime.
-
-;;; Old comment: This used to happen only in
-;;; GET-DYNAMIC-FOREIGN-SYMBOL-ADDRESS, and only if no libraries were
-;;; dlopen()ed already, but that didn't work if something was
-;;; dlopen()ed before any problem global vars were used. So now we do
-;;; this in any function that can add to the *HANDLES-FROM-DLOPEN*, as
-;;; well as in GET-DYNAMIC-FOREIGN-SYMBOL-ADDRESS.
-
-;;; FIXME: It would work just as well to do it once at startup, actually.
-;;; Then at least we know it's done. -dan 2001.05.10
-
-(defun ensure-runtime-symbol-table-opened ()
- (unless *handles-from-dlopen*
- ;; Prevent recursive call if dlopen() isn't defined.
- (setf *handles-from-dlopen* (int-sap 0))
- (setf *handles-from-dlopen* (list (dlopen nil rtld-lazy)))
- (when (zerop (sb-sys:sap-int (first *handles-from-dlopen*)))
- (error "can't open our own binary's symbol table: ~S" (dlerror)))))
-
-(defun load-1-foreign (file)
- "the primitive upon which the more general LOAD-FOREIGN is built: load
- a single foreign object file
-
- To use LOAD-1-FOREIGN, at the Unix command line do this:
- echo 'int summish(int x, int y) { return 1 + x + y; }' > /tmp/ffi-test.c
- make /tmp/ffi-test.o # i.e. cc -c -o /tmp/ffi-test.o /tmp/ffi-test.c
- ld -shared -o /tmp/ffi-test.so /tmp/ffi-test.o
- then in SBCL do this:
- (LOAD-1-FOREIGN \"/tmp/ffi-test.so\")
- (DEFINE-ALIEN-ROUTINE SUMMISH INT (X INT) (Y INT))
- Now running (SUMMISH 10 20) should return 31.
-"
- (ensure-runtime-symbol-table-opened)
- ;; Note: We use RTLD-GLOBAL so that it can find all the symbols
- ;; previously loaded. We use RTLD-NOW so that dlopen() will fail if
- ;; not all symbols are defined.
- (let* ((real-file (or (unix-namestring file) file))
- (sap (dlopen real-file (logior rtld-now rtld-global))))
- (if (zerop (sap-int sap))
- (error "can't open object ~S: ~S" real-file (dlerror))
- (pushnew sap *handles-from-dlopen* :test #'sap=)))
- (values))
-
-(defun get-dynamic-foreign-symbol-address (symbol)
- (ensure-runtime-symbol-table-opened)
- ;; Find the symbol in any of the loaded object files. Search in
- ;; reverse order of loading, so that later loadings take precedence.
- ;;
- ;; FIXME: The way that we use PUSHNEW SAP in LOAD-1-FOREIGN means
- ;; that the list isn't guaranteed to be in reverse order of loading,
- ;; at least not if a file is loaded more than once. Is this the
- ;; right thing? (In what cases does it matter?)
- (dolist (handle *handles-from-dlopen*)
- ;; KLUDGE: We implicitly exclude the possibility that the variable
- ;; could actually be NULL, but the man page for dlsym(3)
- ;; recommends doing a more careful test. -- WHN 20000825
- (let ((possible-result (sap-int (dlsym handle symbol))))
- (unless (zerop possible-result)
- (return possible-result)))))
-
-(defun load-foreign (files
- &key
- (libraries '("-lc"))
- ;; FIXME: The old documentation said
- ;; The BASE-FILE argument is used to specify a
- ;; file to use as the starting place for
- ;; defined symbols. The default is the C start
- ;; up code for Lisp.
- ;; But the code ignored the BASE-FILE argument.
- ;; The comment above
- ;; (DECLARE (IGNORE BASE-FILE))
- ;; said
- ;; dlopen() remembers the name of an object,
- ;; when dlopen()ing the same name twice, the
- ;; old object is reused.
- ;; So I deleted all reference to BASE-FILE,
- ;; including the now-bogus reference to the
- ;; BASE-FILE argument in the documentation. But
- ;; are there any other subtleties of the new code
- ;; which need to be documented in its place?
- (env nil env-p)
- (environment (if env-p
- (unix-environment-sbcl-from-cmu env)
- (posix-environ))
- environment-p))
- #+sb-doc
- "LOAD-FOREIGN loads a list of C object files into a running Lisp. The FILES
- argument should be a single file or a list of files. The files may be
- specified as namestrings or as pathnames. The libraries argument should be a
- list of library files as would be specified to ld. They will be searched in
- the order given. The default is just \"-lc\", i.e., the C library. The
- ENVIRONMENT argument is a list of SIMPLE-STRINGs corresponding to the Unix
- environment (\"man environ\") definitions for the invocation of the linker.
- The default is the environment that Lisp is itself running in. Instead of
- using the ENVIRONMENT argument, it is also possible to use the ENV argument,
- using the older, lossy CMU CL representation."
- (when (and env-p environment-p)
- (error "can't specify :ENV and :ENVIRONMENT simultaneously"))
- (let ((output-file (pick-temporary-file-name
- (concatenate 'string "/tmp/~D~C" (string (gensym)))))
- (error-output (make-string-output-stream)))
-
- (/show "running" *dso-linker*)
- (force-output)
- (unwind-protect
- (let ((proc (sb-ext:run-program
- *dso-linker*
- (append *dso-linker-options*
- (list output-file)
- (append (mapcar (lambda (name)
- (unix-namestring name nil))
- (if (atom files)
- (list files)
- files))
- libraries))
- :environment environment
- :input nil
- :output error-output
- :error :output)))
- (unless proc
- (error "could not run ~A" *dso-linker*))
- (unless (zerop (sb-ext:process-exit-code proc))
- (sb-sys:serve-all-events 0)
- (error "~A failed:~%~A" *dso-linker*
- (get-output-stream-string error-output)))
- (load-1-foreign output-file))
- #-sb-show (sb-unix:unix-unlink output-file)
- #+sb-show (/show "not unlinking" output-file)))) ; so we can look at it
-
-) ; PROGN
+(in-package "SB!IMPL")
+
+#!-(or elf mach-o win32)
+(error "Not an ELF, Mach-O, or Win32 platform?")
+
+(defun extern-alien-name (name)
+ (handler-case
+ (coerce name 'base-string)
+ (error ()
+ (error "invalid external alien name: ~S" name))))
+
+;;; *STATIC-FOREIGN-SYMBOLS* are static as opposed to "dynamic" (not
+;;; as opposed to C's "extern"). The table contains symbols known at
+;;; the time that the program was built, but not symbols defined in
+;;; object files which have been loaded dynamically since then.
+#!-sb-dynamic-core
+(declaim (type hash-table *static-foreign-symbols*))
+#!-sb-dynamic-core
+(defvar *static-foreign-symbols* (make-hash-table :test 'equal))
+
+(declaim
+ (ftype (sfunction (string hash-table) (or integer null)) find-foreign-symbol-in-table))
+(defun find-foreign-symbol-in-table (name table)
+ (let ((extern (extern-alien-name name)))
+ (values
+ (or (gethash extern table)
+ (gethash (concatenate 'base-string "ldso_stub__" extern) table)))))
+
+(defun find-foreign-symbol-address (name)
+ "Returns the address of the foreign symbol NAME, or NIL. Does not enter the
+symbol in the linkage table, and never returns an address in the linkage-table."
+ (or #!-sb-dynamic-core
+ (find-foreign-symbol-in-table name *static-foreign-symbols*)
+ (find-dynamic-foreign-symbol-address name)))
+
+(defun foreign-symbol-address (name &optional datap)
+ "Returns the address of the foreign symbol NAME. DATAP must be true if the
+symbol designates a variable (used only on linkage-table platforms). Returns a
+secondary value that is true if DATAP was true and the symbol is a dynamic
+foreign symbol.
+
+On linkage-table ports the returned address is always static: either direct
+address of a static symbol, or the linkage-table address of a dynamic one.
+Dynamic symbols are entered into the linkage-table if they aren't there already.
+
+On non-linkage-table ports signals an error if the symbol isn't found."
+ (declare (ignorable datap))
+ #!+sb-dynamic-core
+ (values (ensure-foreign-symbol-linkage name datap) t)
+ #!-sb-dynamic-core
+ (let ((static (find-foreign-symbol-in-table name *static-foreign-symbols*)))
+ (if static
+ (values static nil)
+ #!+os-provides-dlopen
+ (progn
+ #-sb-xc-host
+ (values #!-linkage-table
+ (ensure-dynamic-foreign-symbol-address name)
+ #!+linkage-table
+ (ensure-foreign-symbol-linkage name datap)
+ t)
+ #+sb-xc-host
+ (error 'undefined-alien-error :name name))
+ #!-os-provides-dlopen
+ (error 'undefined-alien-error :name name))))
+
+(defun foreign-symbol-sap (symbol &optional datap)
+ "Returns a SAP corresponding to the foreign symbol. DATAP must be true if the
+symbol designates a variable (used only on linkage-table platforms). May enter
+the symbol into the linkage-table. On non-linkage-table ports signals an error
+if the symbol isn't found."
+ (declare (ignorable datap))
+ #!-linkage-table
+ (int-sap (foreign-symbol-address symbol))
+ #!+linkage-table
+ (multiple-value-bind (addr sharedp)
+ (foreign-symbol-address symbol datap)
+ #+sb-xc-host #!-sb-dynamic-core (aver (not sharedp)) ()
+ ;; If the address is from linkage-table and refers to data
+ ;; we need to do a bit of juggling. It is not the address of the
+ ;; variable, but the address where the real address is stored.
+ (if (and sharedp datap)
+ (int-sap (sap-ref-word (int-sap addr) 0))
+ (int-sap addr))))
+
+#-sb-xc-host
+(defun foreign-reinit ()
+ #!+os-provides-dlopen
+ (reopen-shared-objects)
+ #!+linkage-table
+ ;; Don't warn about undefined aliens on startup. The same core can
+ ;; reasonably be expected to work with different versions of the
+ ;; same library.
+ (handler-bind ((style-warning #'muffle-warning))
+ (update-linkage-table)))
+
+;;; Cleanups before saving a core
+#-sb-xc-host
+(defun foreign-deinit ()
+ #!+(and os-provides-dlopen (not linkage-table))
+ (when (dynamic-foreign-symbols-p)
+ (warn "~@<Saving cores with alien definitions referring to non-static ~
+ foreign symbols is unsupported on this platform: references to ~
+ such foreign symbols from the restarted core will not work. You ~
+ may be able to work around this limitation by reloading all ~
+ foreign definitions and code using them in the restarted core, ~
+ but no guarantees.~%~%Dynamic foreign symbols in this core: ~
+ ~{~A~^, ~}~:@>" (list-dynamic-foreign-symbols)))
+ #!+os-provides-dlopen
+ (close-shared-objects))
+
+(declaim (maybe-inline sap-foreign-symbol))
+(defun sap-foreign-symbol (sap)
+ (declare (ignorable sap))
+ #-sb-xc-host
+ (let ((addr (sap-int sap)))
+ (declare (ignorable addr))
+ #!+linkage-table
+ (when (<= sb!vm:linkage-table-space-start
+ addr
+ sb!vm:linkage-table-space-end)
+ (dohash ((name-and-datap table-addr) *linkage-info* :locked t)
+ (when (and (<= table-addr addr)
+ (< addr (+ table-addr sb!vm:linkage-table-entry-size)))
+ (return-from sap-foreign-symbol (car name-and-datap)))))
+ #!+os-provides-dladdr
+ (with-alien ((info (struct dl-info
+ (filename c-string)
+ (base unsigned)
+ (symbol c-string)
+ (symbol-address unsigned)))
+ (dladdr (function unsigned unsigned (* (struct dl-info)))
+ :extern "dladdr"))
+ (let ((err (without-gcing
+ ;; On eg. Darwin GC can could otherwise interrupt
+ ;; the call while dladdr is holding a lock.
+ (alien-funcall dladdr addr (addr info)))))
+ (if (zerop err)
+ nil
+ (slot info 'symbol))))
+ ;; FIXME: Even in the absence of dladdr we could search the
+ ;; static foreign symbols (and *linkage-info*, for that matter).
+ ))
+
+;;; How we learn about foreign symbols and dlhandles initially
+(defvar *!initial-foreign-symbols*)
+
+#-sb-xc-host
+(defun !foreign-cold-init ()
+ #!-sb-dynamic-core
+ (dolist (symbol *!initial-foreign-symbols*)
+ (setf (gethash (car symbol) *static-foreign-symbols*) (cdr symbol)))
+ #!+sb-dynamic-core
+ (loop for table-address from sb!vm::linkage-table-space-start
+ by sb!vm::linkage-table-entry-size
+ and reference in sb!vm::*required-runtime-c-symbols*
+ do (setf (gethash reference *linkage-info*) table-address))
+ #!+os-provides-dlopen
+ (setf *runtime-dlhandle* (dlopen-or-lose))
+ #!+os-provides-dlopen
+ (setf *shared-objects* nil))
+
+#!-os-provides-dlopen
+(define-unsupported-fun load-shared-object)
projects / sbcl.git / blobdiff