1.0.27.44: genesis fixes
authorChristophe Rhodes <csr21@cantab.net>
Fri, 24 Apr 2009 15:56:10 +0000 (15:56 +0000)
committerChristophe Rhodes <csr21@cantab.net>
Fri, 24 Apr 2009 15:56:10 +0000 (15:56 +0000)
commitfb2f167e3ea360de1eb1c436de948df5086a6292
tree22c2509e239f70be15db1c2c2fa7011554351a59
parent0408e5d19ea46776d7bdad4a46f643e5e9c27bfe
1.0.27.44: genesis fixes

make genesis of identical fasls produce identical cold cores.

4 messages follow:

documentation handling

CLISP supports documentation for packages now, so remove the read-time
conditional.  However, don't try to use the documentation for the CL or
KEYWORD packages (as they come from the host directly)

LAYOUT clos hash values

Set them in cold-init using the target's RANDOM rather than in genesis
using the host's.

hash table traversal in genesis

MAPHASH will not give repeatable results in general, and certainly won't
between distinct implementations of hash tables.  Sort the contents of
hash tables according to a predicate which completely orders the
contents.  (This is mildly tricky for FDEFN names: we have to assume
that we are only dealing with names of the forms SYMBOL and (SETF
SYMBOL)).

give smallvecs an initial element

Whoops.  The smallvecs (representing the memory image of the core being
constructed) were being constructed without an initial-element.  For the
most part this wouldn't matter, because it will (almost) all be
overwritten by the genesis process itself.  The crux is in that
(almost), though; in some cases it matters, such as producing bogus
values for symbol tls slots.  Mostly implementations seem to zero-fill
newly-constructed (unsigned-byte 8) arrays, but there seem to be some
circumstances under which CLISP will produce one with random data in
it...
NEWS
src/code/class.lisp
src/cold/set-up-cold-packages.lisp
src/compiler/generic/genesis.lisp
version.lisp-expr