December 3rd 2004 #
random, December 3rd 2004
More alien goodness for SBCL (in 0.8.17.19): late resolution of foreign symbols.
* (define-alien-routine foobar int (a int)) ; ; caught STYLE-WARNING: ; Undefined alien: "foobar" ; compilation unit finished ; caught 1 STYLE-WARNING condition FOOBAR * (foobar 7) debugger invoked on a UNDEFINED-ALIEN-ERROR in thread 61938: Attempt to access an undefined alien value. You can type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [ABORT ] Reduce debugger level (leaving debugger, returning to toplevel). 1: [TOPLEVEL] Restart at toplevel READ/EVAL/PRINT loop. (UNDEFINED-ALIEN-ERROR 0)[:EXTERNAL] 0] a * (load-shared-object "foobar.so") #P"/m/nfs1.niksula/home0/u2/tsiivola/src/sbcl/foobar.so" * (foobar 7) 10
Behind the scenes
We resolve foreign symbol addresses to a dedicated, protected page if we can't figure out the real address (this happens when the alien is undefined, meaning the shared object file isn't loaded yet.)
The address gets stored in the linkage table. When new a shared object is loaded into the image, the linkage-table is updated if there are any undefined alien references in the image. This replaces the guard page dummy addresses by the real addresses for those aliens whose definitions were in the loaded object.
At any time, if an undefined alien is accessed (either variable access or function call), we get trapped by the guard page instead, and signal an error.
Todo
SB-ALIEN:UNDEFINED-ALIEN-ERROR doesn't identify the alien by name, or even differentiate between variables and functions. Nor does it occupy a sensible place in the condition hierarchy. Patches welcome.