| blob | 2e68ef4a55232568c194ef4ee530cf4fdc23babc |
1 ;;;; "cold" core image builder: This is how we create a target Lisp
2 ;;;; system from scratch, by converting from fasl files to an image
3 ;;;; file in the cross-compilation host, without the help of the
4 ;;;; target Lisp system.
5 ;;;;
6 ;;;; As explained by Rob MacLachlan on the CMU CL mailing list Wed, 06
7 ;;;; Jan 1999 11:05:02 -0500, this cold load generator more or less
8 ;;;; fakes up static function linking. I.e. it makes sure that all the
9 ;;;; DEFUN-defined functions in the fasl files it reads are bound to the
10 ;;;; corresponding symbols before execution starts. It doesn't do
11 ;;;; anything to initialize variable values; instead it just arranges
12 ;;;; for !COLD-INIT to be called at cold load time. !COLD-INIT is
13 ;;;; responsible for explicitly initializing anything which has to be
14 ;;;; initialized early before it transfers control to the ordinary
15 ;;;; top level forms.
16 ;;;;
17 ;;;; (In CMU CL, and in SBCL as of 0.6.9 anyway, functions not defined
18 ;;;; by DEFUN aren't set up specially by GENESIS. In particular,
19 ;;;; structure slot accessors are not set up. Slot accessors are
20 ;;;; available at cold init time because they're usually compiled
21 ;;;; inline. They're not available as out-of-line functions until the
22 ;;;; toplevel forms installing them have run.)
24 ;;;; This software is part of the SBCL system. See the README file for
25 ;;;; more information.
26 ;;;;
27 ;;;; This software is derived from the CMU CL system, which was
28 ;;;; written at Carnegie Mellon University and released into the
29 ;;;; public domain. The software is in the public domain and is
30 ;;;; provided with absolutely no warranty. See the COPYING and CREDITS
31 ;;;; files for more information.
35 ;;; a magic number used to identify our core files
42 ;;; the current version of SBCL core files
43 ;;;
44 ;;; FIXME: This is left over from CMU CL, and not well thought out.
45 ;;; It's good to make sure that the runtime doesn't try to run core
46 ;;; files from the wrong version, but a single number is not the ideal
47 ;;; way to do this in high level data like this (as opposed to e.g. in
48 ;;; IP packets), and in fact the CMU CL version number never ended up
49 ;;; being incremented past 0. A better approach might be to use a
50 ;;; string which is set from CVS data. (Though now as of sbcl-0.7.8 or
51 ;;; so, we have another problem that the core incompatibility
52 ;;; detection mechanisms are on such a hair trigger -- with even
53 ;;; different builds from the same sources being considered
54 ;;; incompatible -- that any coarser-grained versioning mechanisms
55 ;;; like this are largely irrelevant as long as the hair-triggering
56 ;;; persists.)
57 ;;;
58 ;;; 0: inherited from CMU CL
59 ;;; 1: rearranged static symbols for sbcl-0.6.8
60 ;;; 2: eliminated non-ANSI %DEFCONSTANT/%%DEFCONSTANT support,
61 ;;; deleted a slot from DEBUG-SOURCE structure
62 ;;; 3: added build ID to cores to discourage sbcl/.core mismatch
63 ;;; 4: added gc page table data
67 #!+sb-doc
68 "Round NUMBER up to be an integral multiple of SIZE."
70 \f
71 ;;;; implementing the concept of "vector" in (almost) portable
72 ;;;; Common Lisp
73 ;;;;
74 ;;;; "If you only need to do such simple things, it doesn't really
75 ;;;; matter which language you use." -- _ANSI Common Lisp_, p. 1, Paul
76 ;;;; Graham (evidently not considering the abstraction "vector" to be
77 ;;;; such a simple thing:-)
83 ;;; an element of a BIGVEC -- a vector small enough that we have
84 ;;; a good chance of it being portable to other Common Lisps
91 ;;; a big vector, implemented as a vector of SMALLVECs
92 ;;;
93 ;;; KLUDGE: This implementation seems portable enough for our
94 ;;; purposes, since realistically every modern implementation is
95 ;;; likely to support vectors of at least 2^16 elements. But if you're
96 ;;; masochistic enough to read this far into the contortions imposed
97 ;;; on us by ANSI and the Lisp community, for daring to use the
98 ;;; abstraction of a large linearly addressable memory space, which is
99 ;;; after all only directly supported by the underlying hardware of at
100 ;;; least 99% of the general-purpose computers in use today, then you
101 ;;; may be titillated to hear that in fact this code isn't really
102 ;;; portable, because as of sbcl-0.7.4 we need somewhat more than
103 ;;; 16Mbytes to represent a core, and ANSI only guarantees that
104 ;;; ARRAY-DIMENSION-LIMIT is not less than 1024. -- WHN 2002-06-13
108 ;;; analogous to SVREF, but into a BIGVEC
114 inner-index)))
120 inner-index)
121 new-value)))
123 ;;; analogous to LENGTH, but for a BIGVEC
124 ;;;
125 ;;; the length of BIGVEC, measured in the number of BVREFable bytes it
126 ;;; can hold
131 ;;; analogous to WRITE-SEQUENCE, but for a BIGVEC
135 stream)))
137 ;;; analogous to READ-SEQUENCE-OR-DIE, but for a BIGVEC
143 ;;; Grow BIGVEC (exponentially, so that large increases in size have
144 ;;; asymptotic logarithmic cost per byte).
156 new-outer-vector))
157 bigvec)
158 \f
159 ;;;; looking up bytes and multi-byte values in a BIGVEC (considering
160 ;;;; it as an image of machine memory on the cross-compilation target)
162 ;;; BVREF-32 and friends. These are like SAP-REF-n, except that
163 ;;; instead of a SAP we use a BIGVEC.
175 (+ byte-index
180 append
185 append
202 ;; lispobj-sized word, whatever that may be
203 ;; hopefully nobody ever wants a 128-bit SBCL...
218 \f
219 ;;;; representation of spaces in the core
221 ;;; If there is more than one dynamic space in memory (i.e., if a
222 ;;; copying GC is in use), then only the active dynamic space gets
223 ;;; dumped to core.
236 "the alignment requirement for spaces in the target.
239 ;;; a GENESIS-time representation of a memory space (e.g. read-only
240 ;;; space, dynamic space, or static space)
243 ;; name and identifier for this GSPACE
246 ;; the word address where the data will be loaded
248 ;; the data themselves. (Note that in CMU CL this was a pair of
249 ;; fields SAP and WORDS-ALLOCATED, but that wasn't very portable.)
250 ;; (And then in SBCL this was a VECTOR, but turned out to be
251 ;; unportable too, since ANSI doesn't think that arrays longer than
252 ;; 1024 (!) should needed by portable CL code...)
254 ;; the index of the next unwritten word (i.e. chunk of
255 ;; SB!VM:N-WORD-BYTES bytes) in BYTES, or equivalently the number of
256 ;; words actually written in BYTES. In order to convert to an actual
257 ;; index into BYTES, thus must be multiplied by SB!VM:N-WORD-BYTES.
270 byte-address
271 target-space-alignment))
273 :identifier identifier
275 \f
276 ;;;; representation of descriptors
279 (:constructor make-descriptor
282 ;; the GSPACE that this descriptor is allocated in, or NIL if not set yet.
284 ;; the offset in words from the start of GSPACE, or NIL if not set yet
286 ;; the high and low halves of the descriptor
287 ;;
288 ;; KLUDGE: Judging from the comments in genesis.lisp of the CMU CL
289 ;; old-rt compiler, this split dates back from a very early version
290 ;; of genesis where 32-bit integers were represented as conses of
291 ;; two 16-bit integers. In any system with nice (UNSIGNED-BYTE 32)
292 ;; structure slots, like CMU CL >= 17 or any version of SBCL, there
293 ;; seems to be no reason to persist in this. -- WHN 19990917
294 high
295 low)
307 "for fixnum: ~W"
310 unsigned))))
318 "for other immediate: #X~X, type #b~8,'0B"
323 "for pointer: #X~X, lowtag #b~3,'0B, ~A"
326 lowtag
332 ;;; Return a descriptor for a block of LENGTH bytes out of GSPACE. The
333 ;;; free word index is boosted as necessary, and if additional memory
334 ;;; is needed, we grow the GSPACE. The descriptor returned is a
335 ;;; pointer of type LOWTAG.
341 ;; Grow GSPACE as necessary until it's big enough to handle
342 ;; NEW-FREE-WORD-INDEX.
347 ;; Now that GSPACE is big enough, we can meaningfully grab a chunk of it.
356 lowtag)
357 gspace
358 old-free-word-index))))
361 #!+sb-doc
362 "the lowtag bits for DES"
372 ;; KLUDGE: The (- SB!VM:N-WORD-BITS 2) term here looks right to
373 ;; me, and it works, but in CMU CL it was (1- SB!VM:N-WORD-BITS),
374 ;; and although that doesn't make sense for me, or work for me,
375 ;; it's hard to see how it could have been wrong, since CMU CL
376 ;; genesis worked. It would be nice to understand how this came
377 ;; to be.. -- WHN 19990901
383 ;; Extract an (unsigned-byte 32), from either its fixnum or bignum
384 ;; representation.
391 ;;; common idioms
397 ;;; If DESCRIPTOR-GSPACE is already set, just return that. Otherwise,
398 ;;; figure out a GSPACE which corresponds to DES, set it into
399 ;;; (DESCRIPTOR-GSPACE DES), set a consistent value into
400 ;;; (DESCRIPTOR-WORD-OFFSET DES), and return the GSPACE.
405 ;; KLUDGE: It's not completely clear to me what's going on here;
406 ;; this is a literal translation from of some rather mysterious
407 ;; code from CMU CL's DESCRIPTOR-SAP function. Some explanation
408 ;; would be nice. -- WHN 19990817
418 ;; This code relies on the fact that GSPACEs are aligned
419 ;; such that the descriptor-low-bits low bits are zero.
429 descriptor-low-bits)))
440 descriptor-low-bits))))
454 type)))
461 offset)
462 type))
466 \f
467 ;;;; miscellaneous variables and other noise
469 ;;; a numeric value to be returned for undefined foreign symbols, or NIL if
470 ;;; undefined foreign symbols are to be treated as an error.
471 ;;; (In the first pass of GENESIS, needed to create a header file before
472 ;;; the C runtime can be built, various foreign symbols will necessarily
473 ;;; be undefined, but we don't need actual values for them anyway, and
474 ;;; we can just use 0 or some other placeholder. In the second pass of
475 ;;; GENESIS, all foreign symbols should be defined, so any undefined
476 ;;; foreign symbol is a problem.)
477 ;;;
478 ;;; KLUDGE: It would probably be cleaner to rewrite GENESIS so that it
479 ;;; never tries to look up foreign symbols in the first place unless
480 ;;; it's actually creating a core file (as in the second pass) instead
481 ;;; of using this hack to allow it to go through the motions without
482 ;;; causing an error. -- WHN 20000825
485 ;;; a handle on the trap object
487 ;; was: (make-other-immediate-descriptor 0 sb!vm:unbound-marker-widetag)
489 ;;; a handle on the NIL object
492 ;;; the head of a list of TOPLEVEL-THINGs describing stuff to be done
493 ;;; when the target Lisp starts up
494 ;;;
495 ;;; Each TOPLEVEL-THING can be a function to be executed or a fixup or
496 ;;; loadtime value, represented by (CONS KEYWORD ..). The FILENAME
497 ;;; tells which fasl file each list element came from, for debugging
498 ;;; purposes.
501 ;;; the name of the object file currently being cold loaded (as a string, not a
502 ;;; pathname), or NIL if we're not currently cold loading any object file
505 \f
506 ;;;; miscellaneous stuff to read and write the core memory
508 ;;; FIXME: should be DEFINE-MODIFY-MACRO
510 #!+sb-doc
511 "Push THING onto the given cold-load LIST."
516 #!+sb-doc
517 "Return the value which is displaced by INDEX words from ADDRESS."
527 #!+sb-doc
528 "Return the value at ADDRESS."
531 ;;; (Note: In CMU CL, this function expected a SAP-typed ADDRESS
532 ;;; value, instead of the SAP-INT we use here.)
534 note-load-time-value-reference))
547 #!+sb-doc
548 "Write VALUE displaced INDEX words from ADDRESS."
549 ;; KLUDGE: There is an algorithm (used in DESCRIPTOR-INTUIT-GSPACE)
550 ;; for calculating the value of the GSPACE slot from scratch. It
551 ;; doesn't work for all values, only some of them, but mightn't it
552 ;; be reasonable to see whether it works on VALUE before we give up
553 ;; because (DESCRIPTOR-GSPACE VALUE) isn't set? (Or failing that,
554 ;; perhaps write a comment somewhere explaining why it's not a good
555 ;; idea?) -- WHN 19990817
561 value)
570 #!+sb-doc
571 "Write VALUE (a DESCRIPTOR) at ADDRESS (also a DESCRIPTOR)."
573 \f
574 ;;;; allocating images of primitive objects in the cold core
576 ;;; There are three kinds of blocks of memory in the type system:
577 ;;; * Boxed objects (cons cells, structures, etc): These objects have no
578 ;;; header as all slots are descriptors.
579 ;;; * Unboxed objects (bignums): There is a single header word that contains
580 ;;; the length.
581 ;;; * Vector objects: There is a header word with the type, then a word for
582 ;;; the length, then the data.
584 #!+sb-doc
585 "Allocate LENGTH words in GSPACE and return a new descriptor of type LOWTAG
586 pointing to them."
589 #!+sb-doc
590 "Allocate LENGTH units of ELEMENT-BITS bits plus a header word in GSPACE and
591 return an ``other-pointer'' descriptor to them. Initialize the header word
592 with the resultant length and TYPE."
600 type))
601 des))
603 #!+sb-doc
604 "Allocate LENGTH units of ELEMENT-BITS size plus a header plus a length slot in
605 GSPACE and return an ``other-pointer'' descriptor to them. Initialize the
606 header word with TYPE and the length slot with LENGTH."
607 ;; FIXME: Here and in ALLOCATE-UNBOXED-OBJECT, BYTES is calculated using
608 ;; #'/ instead of #'CEILING, which seems wrong.
617 des))
618 \f
619 ;;;; copying simple objects into the cold core
622 #!+sb-doc
623 "Copy STRING (which must only contain STANDARD-CHARs) into the cold
624 core and return a descriptor to it."
625 ;; (Remember that the system convention for storage of strings leaves an
626 ;; extra null byte at the end to aid in call-out to C.)
643 des))
646 #!+sb-doc
647 "Copy a bignum to the cold core."
651 words
658 ;; FIXME: Shouldn't this be a fatal error?
660 words n remainder)))
665 word)))))
666 handle))
669 #!+sb-doc
670 "Makes a number pair of TYPE (ratio or complex) and fills it in."
674 des))
684 (:little-endian
687 (:big-endian
694 ;; Just guessing.
698 address))
703 ;; 64-bit platforms have immediate single-floats.
715 des))
732 des))
744 ;;; Copy the given number to the core.
756 #!+long-float
774 des))
776 ;;; Allocate a cons cell in GSPACE and fill it in with CAR and CDR.
781 dest))
783 ;;; Make a simple-vector on the target that holds the specified
784 ;;; OBJECTS, and return its descriptor.
792 result))
793 \f
794 ;;;; symbol magic
796 ;;; FIXME: This should be a &KEY argument of ALLOCATE-SYMBOL.
799 ;;; Allocate (and initialize) a symbol.
815 symbol))
817 ;;; Set the cold symbol value of SYMBOL-OR-SYMBOL-DES, which can be either a
818 ;;; descriptor of a cold symbol or (in an abbreviation for the
819 ;;; most common usage pattern) an ordinary symbol, which will be
820 ;;; automatically cold-interned.
827 \f
828 ;;;; layouts and type system pre-initialization
830 ;;; Since we want to be able to dump structure constants and
831 ;;; predicates with reference layouts, we need to create layouts at
832 ;;; cold-load time. We use the name to intern layouts by, and dump a
833 ;;; list of all cold layouts in *!INITIAL-LAYOUTS* so that type system
834 ;;; initialization can find them. The only thing that's tricky [sic --
835 ;;; WHN 19990816] is initializing layout's layout, which must point to
836 ;;; itself.
838 ;;; a map from class names to lists of
839 ;;; `(,descriptor ,name ,length ,inherits ,depth)
840 ;;; KLUDGE: It would be more understandable and maintainable to use
841 ;;; DEFSTRUCT (:TYPE LIST) here. -- WHN 19990823
844 ;;; a map from DESCRIPTOR-BITS of cold layouts to the name, for inverting
845 ;;; mapping
848 ;;; FIXME: *COLD-LAYOUTS* and *COLD-LAYOUT-NAMES* should be
849 ;;; initialized by binding in GENESIS.
851 ;;; the descriptor for layout's layout (needed when making layouts)
858 ;; KLUDGE: this is a little bit sleazy, but the tricky thing is that
859 ;; structure slots don't have a terribly firm idea of their names.
860 ;; At least here if we change LAYOUT's package of definition, we
861 ;; only have to change one thing...
872 cold-layout
874 value))
876 ;;; Return a list of names created from the cold layout INHERITS data
877 ;;; in X.
888 index
893 descriptor)
894 make-cold-layout))
897 ;; KLUDGE: Why 1+? -- WHN 19990901
898 ;; header word? -- CSR 20051204
905 ;; KLUDGE: The offsets into LAYOUT below should probably be pulled out
906 ;; of the cross-compiler's tables at genesis time instead of inserted
907 ;; by hand as bare numeric constants. -- WHN ca. 19990901
909 ;; Set slot 0 = the layout of the layout.
912 ;; Set the CLOS hash value.
913 ;;
914 ;; Note: CMU CL didn't set these in genesis, but instead arranged
915 ;; for them to be set at cold init time. That resulted in slightly
916 ;; kludgy-looking code, but there were at least two things to be
917 ;; said for it:
918 ;; 1. It put the hash values under the control of the target Lisp's
919 ;; RANDOM function, so that CLOS behavior would be nearly
920 ;; deterministic (instead of depending on the implementation of
921 ;; RANDOM in the cross-compilation host, and the state of its
922 ;; RNG when genesis begins).
923 ;; 2. It automatically ensured that all hash values in the target Lisp
924 ;; were part of the same sequence, so that we didn't have to worry
925 ;; about the possibility of the first hash value set in genesis
926 ;; being precisely equal to the some hash value set in cold init time
927 ;; (because the target Lisp RNG has advanced to precisely the same
928 ;; state that the host Lisp RNG was in earlier).
929 ;; Point 1 should not be an issue in practice because of the way we do our
930 ;; build procedure in two steps, so that the SBCL that we end up with has
931 ;; been created by another SBCL (whose RNG is under our control).
932 ;; Point 2 is more of an issue. If ANSI had provided a way to feed
933 ;; entropy into an RNG, we would have no problem: we'd just feed
934 ;; some specialized genesis-time-only pattern into the RNG state
935 ;; before using it. However, they didn't, so we have a slight
936 ;; problem. We address it by generating the hash values using a
937 ;; different algorithm than we use in ordinary operation.
939 ;; to make sure that it's not something which is (1)
940 ;; evenly distributed and (2) not foreordained to arise in
941 ;; the target Lisp's (RANDOM-LAYOUT-CLOS-HASH) sequence
942 ;; and show up as the CLOS-HASH value of some other
943 ;; LAYOUT.
952 ;; Set other slot values.
953 ;;
954 ;; leave CLASSOID uninitialized for now
966 name
973 result))
979 ;; We initially create the layout of LAYOUT itself with NIL as the LAYOUT and
980 ;; #() as INHERITS,
993 ;; Then we create the layouts that we'll need to make a correct INHERITS
994 ;; vector for the layout of LAYOUT itself..
995 ;;
996 ;; FIXME: The various LENGTH and DEPTHOID numbers should be taken from
997 ;; the compiler's tables, not set by hand.
1017 so-layout
1018 bso-layout)))
1020 ;; ..and return to backpatch the layout of LAYOUT.
1024 \f
1025 ;;;; interning symbols in the cold image
1027 ;;; In order to avoid having to know about the package format, we
1028 ;;; build a data structure in *COLD-PACKAGE-SYMBOLS* that holds all
1029 ;;; interned symbols along with info about their packages. The data
1030 ;;; structure is a list of sublists, where the sublists have the
1031 ;;; following format:
1032 ;;; (<make-package-arglist>
1033 ;;; <internal-symbols>
1034 ;;; <external-symbols>
1035 ;;; <imported-internal-symbols>
1036 ;;; <imported-external-symbols>
1037 ;;; <shadowing-symbols>
1038 ;;; <package-documentation>)
1039 ;;;
1040 ;;; KLUDGE: It would be nice to implement the sublists as instances of
1041 ;;; a DEFSTRUCT (:TYPE LIST). (They'd still be lists, but at least we'd be
1042 ;;; using mnemonically-named operators to access them, instead of trying
1043 ;;; to remember what THIRD and FIFTH mean, and hoping that we never
1044 ;;; need to change the list layout..) -- WHN 19990825
1046 ;;; an alist from packages to lists of that package's symbols to be dumped
1050 ;;; a map from descriptors to symbols, so that we can back up. The key
1051 ;;; is the address in the target core.
1055 ;;; sanity check for a symbol we're about to create on the target
1056 ;;;
1057 ;;; Make sure that the symbol has an appropriate package. In
1058 ;;; particular, catch the so-easy-to-make error of typing something
1059 ;;; like SB-KERNEL:%BYTE-BLT in cold sources when what you really
1060 ;;; need is SB!KERNEL:%BYTE-BLT.
1064 ;; Cold interning things in these standard packages is OK. (Cold
1065 ;; interning things in the other standard package, CL-USER, isn't
1066 ;; OK. We just use CL-USER to expose symbols whose homes are in
1067 ;; other packages. Thus, trying to cold intern a symbol whose
1068 ;; home package is CL-USER probably means that a coding error has
1069 ;; been made somewhere.)
1071 ;; Cold interning something in one of our target-code packages,
1072 ;; which are ever-so-rigorously-and-elegantly distinguished by
1073 ;; this prefix on their names, is OK too.
1075 ;; This one is OK too, since it ends up being COMMON-LISP on the
1076 ;; target.
1078 ;; Anything else looks bad. (maybe COMMON-LISP-USER? maybe an extension
1079 ;; package in the xc host? something we can't think of
1080 ;; a valid reason to cold intern, anyway...)
1081 )))
1083 ;;; like SYMBOL-PACKAGE, but safe for symbols which end up on the target
1084 ;;;
1085 ;;; Most host symbols we dump onto the target are created by SBCL
1086 ;;; itself, so that as long as we avoid gratuitously
1087 ;;; cross-compilation-unfriendly hacks, it just happens that their
1088 ;;; SYMBOL-PACKAGE in the host system corresponds to their
1089 ;;; SYMBOL-PACKAGE in the target system. However, that's not the case
1090 ;;; in the COMMON-LISP package, where we don't get to create the
1091 ;;; symbols but instead have to use the ones that the xc host created.
1092 ;;; In particular, while ANSI specifies which symbols are exported
1093 ;;; from COMMON-LISP, it doesn't specify that their home packages are
1094 ;;; COMMON-LISP, so the xc host can keep them in random packages which
1095 ;;; don't exist on the target (e.g. CLISP keeping some CL-exported
1096 ;;; symbols in the CLOS package).
1098 ;; We want to catch weird symbols like CLISP's
1099 ;; CL:FIND-METHOD=CLOS::FIND-METHOD, but we don't want to get
1100 ;; sidetracked by ordinary symbols like :CHARACTER which happen to
1101 ;; have the same SYMBOL-NAME as exports from COMMON-LISP.
1106 ;; special case, to work around possible xc host weirdness
1107 ;; in COMMON-LISP package
1109 ;; ordinary case
1114 result))))
1116 ;;; Return a handle on an interned symbol. If necessary allocate the
1117 ;;; symbol and record which package the symbol was referenced in. When
1118 ;;; we allocate the symbol, make sure we record a reference to the
1119 ;;; symbol in the home package so that the package gets set.
1121 &optional
1126 ;; Anything on the cross-compilation host which refers to the target
1127 ;; machinery through the host SB-XC package should be translated to
1128 ;; something on the target which refers to the same machinery
1129 ;; through the target COMMON-LISP package.
1137 ;; in COLD-INTERN-INFO.
1138 ;; (CAR COLD-INTERN-INFO) = descriptor of symbol
1139 ;; (CDR COLD-INTERN-INFO) = list of packages, other than symbol's
1140 ;; own package, referring to symbol
1141 ;; (*COLD-PACKAGE-SYMBOLS* and *COLD-SYMBOLS* store basically the
1142 ;; same information, but with the mapping running the opposite way.)
1167 ;;; Construct and return a value for use as *NIL-DESCRIPTOR*.
1180 1
1182 0
1186 result)
1189 result)
1192 result)
1195 ;; This is *DYNAMIC*, and DES is *STATIC*,
1196 ;; because that's the way CMU CL did it; I'm
1197 ;; not sure whether there's an underlying
1198 ;; reason. -- WHN 1990826
1202 result)
1206 result))
1208 ;;; Since the initial symbols must be allocated before we can intern
1209 ;;; anything else, we intern those here. We also set the value of T.
1211 #!+sb-doc
1212 "Initialize the cold load symbol-hacking data structures."
1214 ;; Intern the others.
1221 ;; FIXME: should be fatal
1223 symbol
1224 nil
1225 offset-found
1226 offset-wanted))))
1227 ;; Establish the value of T.
1230 ;; Establish the value of *PSEUDO-ATOMIC-BITS* so that the
1231 ;; allocation sequences that expect it to be zero upon entrance
1232 ;; actually find it to be so.
1237 ;;; a helper function for FINISH-SYMBOLS: Return a cold alist suitable
1238 ;;; to be stored in *!INITIAL-LAYOUTS*.
1244 result))
1246 result))
1248 ;;; Establish initial values for magic symbols.
1249 ;;;
1250 ;;; Scan over all the symbols referenced in each package in
1251 ;;; *COLD-PACKAGE-SYMBOLS* making that for each one there's an
1252 ;;; appropriate entry in the *!INITIAL-SYMBOLS* data structure to
1253 ;;; intern it.
1256 ;; I think the point of setting these functions into SYMBOL-VALUEs
1257 ;; here, instead of using SYMBOL-FUNCTION, is that in CMU CL
1258 ;; SYMBOL-FUNCTION reduces to FDEFINITION, which is a pretty
1259 ;; hairy operation (involving globaldb.lisp etc.) which we don't
1260 ;; want to invoke early in cold init. -- WHN 2001-12-05
1261 ;;
1262 ;; FIXME: So OK, that's a reasonable reason to do something weird like
1263 ;; this, but this is still a weird thing to do, and we should change
1264 ;; the names to highlight that something weird is going on. Perhaps
1265 ;; *MAYBE-GC-FUN*, *INTERNAL-ERROR-FUN*, *HANDLE-BREAKPOINT-FUN*,
1266 ;; and *HANDLE-FUN-END-BREAKPOINT-FUN*...
1294 ;; FIXME: Add assertions here to make sure that inappropriate stuff
1295 ;; isn't being dumped:
1296 ;; * the CL-USER package
1297 ;; * the SB-COLD package
1298 ;; * any internal symbols in the CL package
1299 ;; * basically any package other than CL, KEYWORD, or the packages
1300 ;; in package-data-list.lisp-expr
1301 ;; and that the structure of the KEYWORD package (e.g. whether
1302 ;; any symbols are internal to it) matches what we want in the
1303 ;; target SBCL.
1305 ;; FIXME: It seems possible that by looking at the contents of
1306 ;; packages in the target SBCL we could find which symbols in
1307 ;; package-data-lisp.lisp-expr are now obsolete. (If I
1308 ;; understand correctly, only symbols which actually have
1309 ;; definitions or which are otherwise referred to actually end
1310 ;; up in the target packages.)
1315 cold-package))))
1320 symbol
1321 cold-package))
1343 internal-count
1344 external-count)
1345 r)
1346 ;; FIXME: It would be more space-efficient to use vectors
1347 ;; instead of lists here, and space-efficiency here would be
1348 ;; nice, since it would reduce the peak memory usage in
1349 ;; genesis and cold init.
1364 ;;; Make a cold list that can be used as the arg list to MAKE-PACKAGE in
1365 ;;; order to make a package that is similar to PKG.
1374 ;; Make the package nickname lists for the standard packages
1375 ;; be the minimum specified by ANSI, regardless of what value
1376 ;; the cross-compilation host happens to use.
1382 '())
1383 ;; For packages other than the
1384 ;; standard packages, the nickname
1385 ;; list was specified by our package
1386 ;; setup code, not by properties of
1387 ;; what cross-compilation host we
1388 ;; happened to use, and we can just
1389 ;; propagate it into the target.
1395 ;; INTERNAL-COUNT and EXTERNAL-COUNT are the number of symbols that
1396 ;; the package contains in the core. We arrange for the package
1397 ;; symbol tables to be created somewhat larger so that they don't
1398 ;; need to be rehashed so easily when additional symbols are
1399 ;; interned during the warm build.
1412 res))
1413 \f
1414 ;;;; functions and fdefinition objects
1416 ;;; a hash table mapping from fdefinition names to descriptors of cold
1417 ;;; objects
1418 ;;;
1419 ;;; Note: Since fdefinition names can be lists like '(SETF FOO), and
1420 ;;; we want to have only one entry per name, this must be an 'EQUAL
1421 ;;; hash table, not the default 'EQL.
1426 ;;; Given a cold representation of a symbol, return a warm
1427 ;;; representation.
1429 ;; Note that COLD-INTERN is responsible for keeping the
1430 ;; *COLD-SYMBOLS* table up to date, so if DES happens to refer to an
1431 ;; uninterned symbol, the code below will fail. But as long as we
1432 ;; don't need to look up uninterned symbols during bootstrapping,
1433 ;; that's OK..
1439 symbol))
1441 ;;; like CL:CAR, CL:CDR, and CL:NULL but for cold values
1452 ;;; Given a cold representation of a function name, return a warm
1453 ;;; representation.
1460 ;; Do cold (DESTRUCTURING-BIND (COLD-CAR COLD-CADR) DES ..).
1471 result))
1493 fdefn))))
1495 ;;; Handle the at-cold-init-time, fset-for-static-linkage operation
1496 ;;; requested by FOP-FSET.
1507 #!+sparc
1508 defn
1509 #!-sparc
1519 fdefn))
1531 ;; FIXME: should be fatal
1533 sym nil offset desired))))))
1541 result))
1542 \f
1543 ;;;; fixups and related stuff
1545 ;;; an EQUAL hash table
1549 ;; Read the sbcl.nm file to find the addresses for foreign-symbols in
1550 ;; the C runtime.
1555 while line do
1556 ;; UNIX symbol tables might have tabs in them, and tabs are
1557 ;; not in Common Lisp STANDARD-CHAR, so there seems to be no
1558 ;; nice portable way to deal with them within Lisp, alas.
1559 ;; Fortunately, it's easy to use UNIX command line tools like
1560 ;; sed to remove the problem, so it's not too painful for us
1561 ;; to push responsibility for converting tabs to spaces out to
1562 ;; the caller.
1563 ;;
1564 ;; Other non-STANDARD-CHARs are problematic for the same reason.
1565 ;; Make sure that there aren't any..
1568 line)))
1571 ch
1572 line)))
1577 ;; KLUDGE: It's too messy to try to understand all
1578 ;; possible output from nm, so we just punt the lines we
1579 ;; don't recognize. We realize that there's some chance
1580 ;; that might get us in trouble someday, so we warn
1581 ;; about it.
1594 name old-value value)))
1619 code-object
1620 offset
1621 &optional
1628 ;; FIXME: Should this be ERROR instead of WARN?
1631 value))
1633 ;;; The x86 port needs to store code fixups along with code objects if
1634 ;;; they are to be moved, so fixups for code objects in the dynamic
1635 ;;; heap need to be noted.
1641 ;; If CODE-OBJECT might be moved
1643 dynamic-core-space-id)
1644 ;; FIXME: pushed thing should be a structure, not just a list
1658 code-object
1668 ;;; Given a pointer to a code object and an offset relative to the
1669 ;;; tail of the code object's header, return an offset relative to the
1670 ;;; (beginning of the) code object.
1671 ;;;
1672 ;;; FIXME: It might be clearer to reexpress
1673 ;;; (LET ((X (CALC-OFFSET CODE-OBJECT OFFSET0))) ..)
1674 ;;; as
1675 ;;; (LET ((X (+ OFFSET0 (CODE-OBJECT-HEADER-N-BYTES CODE-OBJECT)))) ..).
1683 result))
1686 do-cold-fixup))
1691 offset-within-code-object))
1695 ;; See CMU CL source for other formerly-supported architectures
1696 ;; (and note that you have to rewrite them to use BVREF-X
1697 ;; instead of SAP-REF).
1698 (:alpha
1700 (:jmp-hint
1702 (:bits-63-48
1710 (:bits-47-32
1717 (:ldah
1723 (:lda
1728 (:hppa
1730 (:load
1735 (:load-short
1742 (:hi
1751 (:branch
1758 (:mips
1760 (:jump
1765 (:lui
1770 (:addi
1775 ;; FIXME: PowerPC Fixups are not fully implemented. The bit
1776 ;; here starts to set things up to work properly, but there
1777 ;; needs to be corresponding code in ppc-vm.lisp
1778 (:ppc
1780 (:ba
1784 (:ha
1792 (:l
1798 (:sparc
1800 (:call
1802 (:sethi
1807 (:add
1814 gspace-byte-offset))
1818 (+ gspace-byte-address
1821 (:absolute
1824 fixed-up)
1825 ;; comment from CMU CL sources:
1826 ;;
1827 ;; Note absolute fixups that point within the object.
1828 ;; KLUDGE: There seems to be an implicit assumption in
1829 ;; the old CMU CL code here, that if it doesn't point
1830 ;; before the object, it must point within the object
1831 ;; (not beyond it). It would be good to add an
1832 ;; explanation of why that's true, or an assertion that
1833 ;; it's really true, or both.
1836 after-header
1837 value
1838 kind))))
1841 gspace-byte-address
1842 gspace-byte-offset
1845 fixed-up)
1846 ;; Note relative fixups that point outside the code
1847 ;; object, which is to say all relative fixups, since
1848 ;; relative addressing within a code object never needs
1849 ;; a fixup.
1851 after-header
1852 value
1853 kind))))))))
1863 ;;; *COLD-FOREIGN-SYMBOL-TABLE* becomes *!INITIAL-FOREIGN-SYMBOLS* in
1864 ;;; the core. When the core is loaded, !LOADER-COLD-INIT uses this to
1865 ;;; create *STATIC-FOREIGN-SYMBOLS*, which the code in
1866 ;;; target-load.lisp refers to.
1872 result))
1879 result))
1882 \f
1883 ;;;; general machinery for cold-loading FASL files
1885 ;;; FOP functions for cold loading
1887 ;; We start out with a copy of the ordinary *FOP-FUNS*. The ones
1888 ;; which aren't appropriate for cold load will be destructively
1889 ;; modified.
1894 ;;; Cause a fop to have a special definition for cold load.
1895 ;;;
1896 ;;; This is similar to DEFINE-FOP, but unlike DEFINE-FOP, this version
1897 ;;; (1) looks up the code for this name (created by a previous
1898 ;; DEFINE-FOP) instead of creating a code, and
1899 ;;; (2) stores its definition in the *COLD-FOP-FUNS* vector,
1900 ;;; instead of storing in the *FOP-FUNS* vector.
1912 forms))
1926 ;;; Cause a fop to be undefined in cold load.
1931 ;;; COLD-LOAD loads stuff into the core image being built by calling
1932 ;;; LOAD-AS-FASL with the fop function table rebound to a table of cold
1933 ;;; loading functions.
1935 #!+sb-doc
1936 "Load the file named by FILENAME into the cold load image being built."
1944 \f
1945 ;;;; miscellaneous cold fops
1974 layout
1989 result))
2000 ;; If a layout of this name has been defined already
2002 ;; Enforce consistency between the previous definition and the
2003 ;; current definition, then return the previous definition.
2005 ;; FIXME: This would be more maintainable if we used
2006 ;; DEFSTRUCT (:TYPE LIST) to define COLD-LAYOUT. -- WHN 19990825
2008 old-name
2009 old-length
2010 old-inherits-list
2011 old-depthoid
2012 old-nuntagged)
2013 old
2025 time length was ~S and current length is ~S"
2026 name
2027 length
2028 old-length))
2031 time inherits were ~S~%~
2032 and current inherits are ~S"
2033 name
2034 inherits-list
2035 old-inherits-list))
2038 time inheritance depthoid was ~S and current inheritance~%~
2039 depthoid is ~S"
2040 name
2041 depthoid
2042 old-depthoid))
2045 time number of untagged slots was ~S and is currently ~S"
2046 name
2047 nuntagged
2048 old-nuntagged)))
2049 old-layout-descriptor)
2050 ;; Make a new definition from scratch.
2052 nuntagged-des))))
2053 \f
2054 ;;;; cold fops for loading symbols
2056 ;;; Load a symbol SIZE characters long from *FASL-INPUT-STREAM* and
2057 ;;; intern that symbol in PACKAGE.
2089 \f
2090 ;;;; cold fops for loading lists
2092 ;;; Make a list of the top LENGTH things on the fop stack. The last
2093 ;;; cdr of the list is set to LAST.
2136 \f
2137 ;;;; cold fops for loading vectors
2146 #!+sb-unicode
2156 size
2164 result))
2197 :start start
2199 result))
2206 len
2213 :start start
2215 result))
2243 (* total-elements
2251 dim)))
2255 result))
2257 \f
2258 ;;;; cold fops for loading numbers
2262 ;; Invoke the ordinary warm version of this fop to push the
2263 ;; number.
2265 ;; Replace the warm fop result with the cold image of the warm
2266 ;; fop result.
2287 \f
2288 ;;;; cold fops for calling (or not calling)
2322 \f
2323 ;;;; cold fops for fixing up circularities
2339 (+ idx
2350 ;;; In the original CMUCL code, this actually explicitly declared PUSHP
2351 ;;; to be T, even though that's what it defaults to in DEFINE-COLD-FOP.
2358 obj)
2359 \f
2360 ;;;; cold fops for loading code objects and functions
2362 ;;; the names of things which have had COLD-FSET used on them already
2363 ;;; (used to make sure that we don't try to statically link a name to
2364 ;;; more than one definition)
2366 ;; This can't be an EQL hash table because names can be conses, e.g.
2367 ;; (SETF CAR).
2385 ;;; Setting this variable shows what code looks like before any
2386 ;;; fixups (or function headers) are applied.
2389 ;;; FIXME: The logic here should be converted into a function
2390 ;;; COLD-CODE-FOP-GUTS (NCONST CODE-SIZE) called by DEFINE-COLD-FOP
2391 ;;; FOP-CODE and DEFINE-COLD-FOP FOP-SMALL-CODE, so that
2392 ;;; variable-capture nastiness like (LET ((NCONST ,NCONST) ..) ..)
2393 ;;; doesn't keep me awake at night.
2400 ;; Note: we round the number of constants up to ensure
2401 ;; that the code vector will be properly aligned.
2406 code-size)
2420 raw-header-n-words
2430 :start start
2432 #!+sb-show
2435 "~&/raw code from code-fop ~W ~W:~%"
2436 nconst
2437 code-size)
2441 "/#X~8,'0x: #X~8,'0x~%"
2444 des)))
2465 offset
2477 ;; KLUDGE: Wiring decisions like this in at
2478 ;; this level ("if it's an x86") instead of a
2479 ;; higher level of abstraction ("if it has such
2480 ;; and such relocation peculiarities (which
2481 ;; happen to be confined to the x86)") is bad.
2482 ;; It would be nice if the code were instead
2483 ;; conditional on some more descriptive
2484 ;; feature, :STICKY-CODE or
2485 ;; :LOAD-GC-INTERACTION or something.
2486 ;;
2487 ;; FIXME: The X86 definition of the function
2488 ;; self slot breaks everything object.tex says
2489 ;; about it. (As far as I can tell, the X86
2490 ;; definition makes it a pointer to the actual
2491 ;; code instead of a pointer back to the object
2492 ;; itself.) Ask on the mailing list whether
2493 ;; this is documented somewhere, and if not,
2494 ;; try to reverse engineer some documentation.
2496 ;; a pointer back to the function object, as
2497 ;; described in CMU CL
2498 ;; src/docs/internals/object.tex
2499 fn
2501 ;; KLUDGE: a pointer to the actual code of the
2502 ;; object, as described nowhere that I can find
2503 ;; -- WHN 19990907
2508 ;; FIXME: We should mask out the type
2509 ;; bits, not assume we know what they
2510 ;; are and subtract them out this way.
2517 fn))
2528 code-object))
2530 #!+linkage-table
2545 ;; Note: we round the number of constants up to ensure that
2546 ;; the code vector will be properly aligned.
2551 length)
2569 :start start
2571 des))
2578 routine
2580 des))
2588 code-object))
2596 code-object))
2597 \f
2598 ;;;; emitting C header file
2608 "(As of sbcl-0.8.14, it came from WRITE-CONFIG-H in genesis.lisp.)"
2609 nil
2610 "This file contains low-level information about the"
2611 "internals of a particular version and configuration"
2612 "of SBCL. It is used by the C compiler to create a runtime"
2613 "support environment, an executable program in the host"
2614 "operating system's native format, which can then be used to"
2615 "load and run 'core' files, which are basically programs"
2624 string))))
2630 ;; propagating *SHEBANG-FEATURES* into the Makefiles
2637 ;; propagating *SHEBANG-FEATURES* into C-level #define's
2643 ;; and miscellaneous constants
2646 "#define SBCL_VERSION_STRING ~S~%"
2657 ;; writing entire families of named constants
2660 ;; were automatically propagated
2661 ;; into the runtime.
2662 "SB!VM"
2663 ;; In SBCL, we also propagate various
2664 ;; magic numbers related to file format,
2665 ;; which live here instead of SB!VM.
2673 priority
2676 constants))
2677 ;; machinery for old-style CMU CL Lisp-to-C
2678 ;; arbitrary renaming, being phased out in favor of
2679 ;; the newer systematic RECORD-WITH-TRANSLATED-NAME
2680 ;; renaming
2683 'simple-string
2684 prefix
2686 priority))
2693 priority)))
2694 ;; machinery for new-style SBCL Lisp-to-C naming
2700 suffixes)
2712 ;; KLUDGE: these constants are sort of important, but there's no
2713 ;; pleasing way to inform the code above about them. So we fake
2714 ;; it for now. nikodemus on #lisp (2004-08-09) suggested simply
2715 ;; exporting every numeric constant from SB!VM; that would work,
2716 ;; but the C runtime would have to be altered to use Lisp-like names
2717 ;; rather than the munged names currently exported. --njf, 2004-08-09
2725 nil)
2726 constants))
2727 ;; One more symbol that doesn't fit into the code above.
2730 9
2732 nil)
2733 constants))
2748 ;; KLUDGE: We're dumping two different kinds of
2749 ;; values here, (1) small codes and (2) machine
2750 ;; addresses. The small codes can be dumped as bare
2751 ;; integer values. The large machine addresses might
2752 ;; cause problems if they're large and represented
2753 ;; as (signed) C integers, so we want to force them
2754 ;; to be unsigned by appending an U to the
2755 ;; literal. We can't dump all the values using the
2756 ;; literal-U syntax, since the assembler doesn't
2757 ;; support that syntax and some of the small
2758 ;; constants can be used in assembler files.
2767 value)
2771 ;; writing information about internal errors
2775 ;; FIXME: this UNLESS should go away (see also FIXME in
2776 ;; interr.lisp) -- APD, 2002-03-05
2780 i)))))
2783 ;; I'm not really sure why this is in SB!C, since it seems
2784 ;; conceptually like something that belongs to SB!VM. In any case,
2785 ;; it's needed C-side.
2790 ;; FIXME: The SPARC has a PSEUDO-ATOMIC-TRAP that differs between
2791 ;; platforms. If we export this from the SB!VM package, it gets
2792 ;; written out as #define trap_PseudoAtomic, which is confusing as
2793 ;; the runtime treats trap_ as the prefix for illegal instruction
2794 ;; type things. We therefore don't export it, but instead do
2795 #!+sparc
2798 "#define PSEUDO_ATOMIC_TRAP ~D /* 0x~:*~X */~%"
2801 ;; possibly this is another candidate for a rename (to
2802 ;; pseudo-atomic-trap-number or pseudo-atomic-magic-constant
2803 ;; [possibly applicable to other platforms])
2819 ;; writing primitive object layouts
2822 "struct ~A {~%"
2865 ;; FIXME: It would be nice to use longer names than NIL and
2866 ;; (particularly) T in #define statements.
2868 ;; FIXME: It would be nice not to need to strip anything
2869 ;; that doesn't get stripped always by C-SYMBOL-NAME.
2872 ;; We actually ran GENESIS, use the real value.
2874 ;; We didn't run GENESIS, so guess at the address.
2880 \f
2881 ;;;; writing map file
2883 ;;; Write a map file describing the cold load. Some of this
2884 ;;; information is subject to change due to relocating GC, but even so
2885 ;;; it can be very handy when attempting to troubleshoot the early
2886 ;;; stages of cold load.
2905 funs)))))
2913 "~%~|
2914 (a note about initially undefined function references: These functions
2915 are referred to by code which is installed by GENESIS, but they are not
2916 installed by GENESIS. This is not necessarily a problem; functions can
2917 be defined later, by cold init toplevel forms, or in files compiled and
2918 loaded at warm init, or elsewhere. As long as they are defined before
2919 they are called, everything should be OK. Things are also OK if the
2920 cross-compiler knew their inline definition and used that everywhere
2921 that they were called before the out-of-line definition is installed,
2922 as is fairly common for structure accessors.)
2940 \f
2941 ;;;; writing core file
2946 ;;; magic numbers to identify entries in a core file
2947 ;;;
2948 ;;; (In case you were wondering: No, AFAIK there's no special magic about
2949 ;;; these which requires them to be in the 38xx range. They're just
2950 ;;; arbitrary words, tested not for being in a particular range but just
2951 ;;; for equality. However, if you ever need to look at a .core file and
2952 ;;; figure out what's going on, it's slightly convenient that they're
2953 ;;; all in an easily recognizable range, and displacing the range away from
2954 ;;; zero seems likely to reduce the chance that random garbage will be
2955 ;;; misinterpreted as a .core file.)
2968 (:little-endian
2971 (:big-endian
2975 num)
2993 "writing ~S byte~:P [~S page~:P] from ~S~%"
2994 total-bytes
2995 pages
2996 gspace)
2999 ;; Note: It is assumed that the GSPACE allocation routines always
3000 ;; allocate whole pages (of size *target-page-size*) and that any
3001 ;; empty gspace between the free pointer and the end of page will
3002 ;; be zero-filled. This will always be true under Mach on machines
3003 ;; where the page size is equal. (RT is 4K, PMAX is 4K, Sun 3 is
3004 ;; 8K).
3011 ;; Write part of a (new) directory entry which looks like this:
3012 ;; GSPACE IDENTIFIER
3013 ;; WORD COUNT
3014 ;; DATA PAGE
3015 ;; ADDRESS
3016 ;; PAGE COUNT
3028 ;;; Create a core file created from the cold loaded image. (This is
3029 ;;; the "initial core file" because core files could be created later
3030 ;;; by executing SAVE-LISP in a running system, perhaps after we've
3031 ;;; added some functionality to the system.)
3039 "[building initial core file in ~S: ~%"
3040 filenamestring)
3048 ;; Write the magic number.
3051 ;; Write the Version entry.
3056 ;; Write the build ID.
3063 ;; Write length of build ID record: BUILD-ID-CORE-ENTRY-TYPE-CODE
3064 ;; word, this length word, and one word for each char of BUILD-ID.
3067 ;; (We write each character as a word in order to avoid
3068 ;; having to think about word alignment issues in the
3069 ;; sbcl-0.7.8 version of coreparse.c.)
3072 ;; Write the New Directory entry header.
3080 ;; Write the initial function.
3088 "~&/(DESCRIPTOR-BITS INITIAL-FUN)=#X~X~%"
3092 ;; Write the End entry.
3100 \f
3101 ;;;; the actual GENESIS function
3103 ;;; Read the FASL files in OBJECT-FILE-NAMES and produce a Lisp core,
3104 ;;; and/or information about a Lisp core, therefrom.
3105 ;;;
3106 ;;; input file arguments:
3107 ;;; SYMBOL-TABLE-FILE-NAME names a UNIX-style .nm file *with* *any*
3108 ;;; *tab* *characters* *converted* *to* *spaces*. (We push
3109 ;;; responsibility for removing tabs out to the caller it's
3110 ;;; trivial to remove them using UNIX command line tools like
3111 ;;; sed, whereas it's a headache to do it portably in Lisp because
3112 ;;; #\TAB is not a STANDARD-CHAR.) If this file is not supplied,
3113 ;;; a core file cannot be built (but a C header file can be).
3114 ;;;
3115 ;;; output files arguments (any of which may be NIL to suppress output):
3116 ;;; CORE-FILE-NAME gets a Lisp core.
3117 ;;; C-HEADER-FILE-NAME gets a C header file, traditionally called
3118 ;;; internals.h, which is used by the C compiler when constructing
3119 ;;; the executable which will load the core.
3120 ;;; MAP-FILE-NAME gets (?) a map file. (dunno about this -- WHN 19990815)
3121 ;;;
3122 ;;; FIXME: GENESIS doesn't belong in SB!VM. Perhaps in %KERNEL for now,
3123 ;;; perhaps eventually in SB-LD or SB-BOOT.
3125 object-file-names
3126 symbol-table-file-name
3127 core-file-name
3128 map-file-name
3129 c-header-dir-name)
3132 "~&beginning GENESIS, ~A~%"
3134 ;; Note: This output summarizing what we're doing is
3135 ;; somewhat telegraphic in style, not meant to imply that
3136 ;; we're not e.g. also creating a header file when we
3137 ;; create a core.
3148 ;; Now that we've successfully read our only input file (by
3149 ;; loading the symbol table, if any), it's a good time to ensure
3150 ;; that there'll be someplace for our output files to go when
3151 ;; we're done.
3158 ;; (This shouldn't matter in normal use, since GENESIS normally
3159 ;; only runs once in any given Lisp image, but it could reduce
3160 ;; confusion if we ever experiment with running, tweaking, and
3161 ;; rerunning genesis interactively.)
3171 read-only-core-space-id
3174 static-core-space-id
3177 dynamic-core-space-id
3183 0
3189 ;; Prepare for cold load.
3194 ;; Initialize the *COLD-SYMBOLS* system with the information
3195 ;; from package-data-list.lisp-expr and
3196 ;; common-lisp-exports.lisp-expr.
3197 ;;
3198 ;; Why do things this way? Historically, the *COLD-SYMBOLS*
3199 ;; machinery was designed and implemented in CMU CL long before
3200 ;; I (WHN) ever heard of CMU CL. It dumped symbols and packages
3201 ;; iff they were used in the cold image. When I added the
3202 ;; package-data-list.lisp-expr mechanism, the idea was to
3203 ;; centralize all information about packages and exports. Thus,
3204 ;; it was the natural place for information even about packages
3205 ;; (such as SB!PCL and SB!WALKER) which aren't used much until
3206 ;; after cold load. This didn't quite match the CMU CL approach
3207 ;; of filling *COLD-SYMBOLS* with symbols which appear in the
3208 ;; cold image and then dumping only those symbols. By explicitly
3209 ;; putting all the symbols from package-data-list.lisp-expr and
3210 ;; from common-lisp-exports.lisp-expr into *COLD-SYMBOLS* here,
3211 ;; we feed our centralized symbol information into the old CMU
3212 ;; CL code without having to change the old CMU CL code too
3213 ;; much. (And the old CMU CL code is still useful for making
3214 ;; sure that the appropriate keywords and internal symbols end
3215 ;; up interned in the target Lisp, which is good, e.g. in order
3216 ;; to make &KEY arguments work right and in order to make
3217 ;; BACKTRACEs into target Lisp system code be legible.)
3232 ;; Make sure that information about the association
3233 ;; between PACKAGE and the symbol named NAME gets
3234 ;; recorded in the cold-intern system or (as a
3235 ;; convenience when dealing with the tree structure
3236 ;; allowed in the PACKAGE-DATA-EXPORTS slot) do
3237 ;; nothing if NAME is NIL.
3248 ;; Cold load.
3253 ;; Tidy up loose ends left by cold loading. ("Postpare from cold load?")
3261 ;; Tell the target Lisp how much stuff we've allocated.
3264 0
3268 0
3272 ;; Write results to files.
3273 ;;
3274 ;; FIXME: I dislike this approach of redefining
3275 ;; *STANDARD-OUTPUT* instead of putting the new stream in a
3276 ;; lexical variable, and it's annoying to have WRITE-MAP (to
3277 ;; *STANDARD-OUTPUT*) not be parallel to WRITE-INITIAL-CORE-FILE
3278 ;; (to a stream explicitly passed as an argument).
3287 t
3288 "#ifndef SBCL_GENESIS_~A~%#define SBCL_GENESIS_~A 1~%"
3289 n n))
3290 ,@body
3292 "#endif /* SBCL_GENESIS_~A */~%"
3315 layout