From: Peter Van Eynde <pvaneynd@de...> - 2001-05-13 06:03:06
> In Linux, the support for prefixing things onto symbols in CMUCL has
> been also co-opted for another purpose, which is related to dynamic
> linking. If the runtime is linked dynamically, symbols in libraries
> that Lisp needs (say, "open") won't show up in sbcl.nm. So, we make
> stubs. src/runtime/ldso-stubs.S includes a funky cpp macro:
> LDSO_STUBIFY(foo) generates a statically linked symbol "ldso_stub__foo"
> that jumps to "foo" when called. Hence the practice of prefixing
> "ldso_stub__" to symbols when we can't find them.
> OK, enough. You can mke the stubs go away when you figure out how to
> embed the symbol names in a core and have them resolve when it restarts.
> (Invent a new kind of fixup?)
The fixup is done by ld.so on loading of the executable. It doesn't know
about the core file, so you either
- use the jump-table which the ld.so does see or
- use dlsym or something to find the location of the libc function and
fixup the core at startup. This would bring most of the core into
memory and would make startup a lot slower I fear. Unless you
concentrate all fixups in a table. And suddenly you are
re-implementing the first solution :-)
> (Look out for an official CCLAN announce one of these months soon. In
> the meantime, http://ww.telent.net/cliki/cclan)
Looks good :-)
It's logic Jim, but not as we know it. | pvaneynd@...
"God, root, what is difference?" - Pitr|
"God is more forgiving." - Dave Aronson| http://cvs2.cons.org/~pvaneynd/
From: William Harold Newman <william.newman@ai...> - 2001-06-07 17:19:59
On Fri, May 11, 2001 at 03:35:45AM +0100, Daniel Barlow wrote:
> The attached patch (against 0.6.12.7) is not that adventurous. It
The patch ("Alpha dynamic loading", plus general dynamic loading and
GENESIS cleanup) has been merged in sbcl-0.6.12.24. Thank you.
> * fixes some of the worst naming decisions (functions in genesis.lisp
> tend to be renamed as some combination of "-COLD-" and the name of the
> equivalent code in target-load), and
(This, and your explanation above (snipped), and your revised comments
made a nice little tutorial introduction to dynamic linking and the
CMUCL/SBCL approach to it, and I understand it somewhat better now.:-)
> * adds dynamic loading support on the Alpha, which eventually turned out
> mostly to involve fiddling with linker options and adding symbols to
Hopefully this will still work. IIRC the only Alpha-related changes I
made were rewriting
#elif defined alpha
and changing the sense of the Alpha-only LDSO_STUBs to
anything-but-X86. Neither of those should affect the Alpha behavior
unless I made a clerical error.
> It passes tests on Alpha: users of other platforms will need to check
> (a) I haven't broken OpenBSD (if its broken on anything else it's most
> likely just a stupid error and easily fixable)
> (b) the #ifdef in ldso-stubs.S is legitimate
The Linux/x86 dynamic loading still works for me, at least well enough
to pass the tiny test in tests/foreign.test.sh.
OpenBSD dynamic loading support has never worked. I've never been
motivated to work on it, since I don't use dynamic loading myself,
since my current Lisp application is a pure portable compute engine
which interacts only with stdin/stdout and files, not trying to do
sockets or graphics or databases or linpack or anything.
FreeBSD dynamic loading support used to work, and I expect it still
works, but I no longer have a FreeBSD machine to test it on.
William Harold Newman <william.newman@...>
pending patches from sbcl-devel:
MNA port of CMU CL fixes (for PCL stuff) 2001-05-30
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C