| blob | 843cc7343f88b8794baea5f46c8d41b49e8c2c11 |
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
1113 result))))
1115 ;;; Return a handle on an interned symbol. If necessary allocate the
1116 ;;; symbol and record which package the symbol was referenced in. When
1117 ;;; we allocate the symbol, make sure we record a reference to the
1118 ;;; symbol in the home package so that the package gets set.
1120 &optional
1125 ;; Anything on the cross-compilation host which refers to the target
1126 ;; machinery through the host SB-XC package should be translated to
1127 ;; something on the target which refers to the same machinery
1128 ;; through the target COMMON-LISP package.
1136 ;; in COLD-INTERN-INFO.
1137 ;; (CAR COLD-INTERN-INFO) = descriptor of symbol
1138 ;; (CDR COLD-INTERN-INFO) = list of packages, other than symbol's
1139 ;; own package, referring to symbol
1140 ;; (*COLD-PACKAGE-SYMBOLS* and *COLD-SYMBOLS* store basically the
1141 ;; same information, but with the mapping running the opposite way.)
1166 ;;; Construct and return a value for use as *NIL-DESCRIPTOR*.
1179 1
1181 0
1185 result)
1188 result)
1191 result)
1194 ;; This is *DYNAMIC*, and DES is *STATIC*,
1195 ;; because that's the way CMU CL did it; I'm
1196 ;; not sure whether there's an underlying
1197 ;; reason. -- WHN 1990826
1201 result)
1205 result))
1207 ;;; Since the initial symbols must be allocated before we can intern
1208 ;;; anything else, we intern those here. We also set the value of T.
1210 #!+sb-doc
1211 "Initialize the cold load symbol-hacking data structures."
1213 ;; Intern the others.
1220 ;; FIXME: should be fatal
1222 symbol
1223 nil
1224 offset-found
1225 offset-wanted))))
1226 ;; Establish the value of T.
1229 ;; Establish the value of *PSEUDO-ATOMIC-BITS* so that the
1230 ;; allocation sequences that expect it to be zero upon entrance
1231 ;; actually find it to be so.
1236 ;;; a helper function for FINISH-SYMBOLS: Return a cold alist suitable
1237 ;;; to be stored in *!INITIAL-LAYOUTS*.
1243 result))
1245 result))
1247 ;;; Establish initial values for magic symbols.
1248 ;;;
1249 ;;; Scan over all the symbols referenced in each package in
1250 ;;; *COLD-PACKAGE-SYMBOLS* making that for each one there's an
1251 ;;; appropriate entry in the *!INITIAL-SYMBOLS* data structure to
1252 ;;; intern it.
1255 ;; I think the point of setting these functions into SYMBOL-VALUEs
1256 ;; here, instead of using SYMBOL-FUNCTION, is that in CMU CL
1257 ;; SYMBOL-FUNCTION reduces to FDEFINITION, which is a pretty
1258 ;; hairy operation (involving globaldb.lisp etc.) which we don't
1259 ;; want to invoke early in cold init. -- WHN 2001-12-05
1260 ;;
1261 ;; FIXME: So OK, that's a reasonable reason to do something weird like
1262 ;; this, but this is still a weird thing to do, and we should change
1263 ;; the names to highlight that something weird is going on. Perhaps
1264 ;; *MAYBE-GC-FUN*, *INTERNAL-ERROR-FUN*, *HANDLE-BREAKPOINT-FUN*,
1265 ;; and *HANDLE-FUN-END-BREAKPOINT-FUN*...
1293 ;; FIXME: Add assertions here to make sure that inappropriate stuff
1294 ;; isn't being dumped:
1295 ;; * the CL-USER package
1296 ;; * the SB-COLD package
1297 ;; * any internal symbols in the CL package
1298 ;; * basically any package other than CL, KEYWORD, or the packages
1299 ;; in package-data-list.lisp-expr
1300 ;; and that the structure of the KEYWORD package (e.g. whether
1301 ;; any symbols are internal to it) matches what we want in the
1302 ;; target SBCL.
1304 ;; FIXME: It seems possible that by looking at the contents of
1305 ;; packages in the target SBCL we could find which symbols in
1306 ;; package-data-lisp.lisp-expr are now obsolete. (If I
1307 ;; understand correctly, only symbols which actually have
1308 ;; definitions or which are otherwise referred to actually end
1309 ;; up in the target packages.)
1314 cold-package))))
1319 symbol
1320 cold-package))
1342 internal-count
1343 external-count)
1344 r)
1345 ;; FIXME: It would be more space-efficient to use vectors
1346 ;; instead of lists here, and space-efficiency here would be
1347 ;; nice, since it would reduce the peak memory usage in
1348 ;; genesis and cold init.
1363 ;;; Make a cold list that can be used as the arg list to MAKE-PACKAGE in
1364 ;;; order to make a package that is similar to PKG.
1373 ;; Make the package nickname lists for the standard packages
1374 ;; be the minimum specified by ANSI, regardless of what value
1375 ;; the cross-compilation host happens to use.
1381 '())
1382 ;; For packages other than the
1383 ;; standard packages, the nickname
1384 ;; list was specified by our package
1385 ;; setup code, not by properties of
1386 ;; what cross-compilation host we
1387 ;; happened to use, and we can just
1388 ;; propagate it into the target.
1394 ;; INTERNAL-COUNT and EXTERNAL-COUNT are the number of symbols that
1395 ;; the package contains in the core. We arrange for the package
1396 ;; symbol tables to be created somewhat larger so that they don't
1397 ;; need to be rehashed so easily when additional symbols are
1398 ;; interned during the warm build.
1411 res))
1412 \f
1413 ;;;; functions and fdefinition objects
1415 ;;; a hash table mapping from fdefinition names to descriptors of cold
1416 ;;; objects
1417 ;;;
1418 ;;; Note: Since fdefinition names can be lists like '(SETF FOO), and
1419 ;;; we want to have only one entry per name, this must be an 'EQUAL
1420 ;;; hash table, not the default 'EQL.
1425 ;;; Given a cold representation of a symbol, return a warm
1426 ;;; representation.
1428 ;; Note that COLD-INTERN is responsible for keeping the
1429 ;; *COLD-SYMBOLS* table up to date, so if DES happens to refer to an
1430 ;; uninterned symbol, the code below will fail. But as long as we
1431 ;; don't need to look up uninterned symbols during bootstrapping,
1432 ;; that's OK..
1438 symbol))
1440 ;;; like CL:CAR, CL:CDR, and CL:NULL but for cold values
1451 ;;; Given a cold representation of a function name, return a warm
1452 ;;; representation.
1459 ;; Do cold (DESTRUCTURING-BIND (COLD-CAR COLD-CADR) DES ..).
1470 result))
1492 fdefn))))
1494 ;;; Handle the at-cold-init-time, fset-for-static-linkage operation
1495 ;;; requested by FOP-FSET.
1506 #!+sparc
1507 defn
1508 #!-sparc
1518 fdefn))
1530 ;; FIXME: should be fatal
1532 sym nil offset desired))))))
1540 result))
1541 \f
1542 ;;;; fixups and related stuff
1544 ;;; an EQUAL hash table
1548 ;; Read the sbcl.nm file to find the addresses for foreign-symbols in
1549 ;; the C runtime.
1554 while line do
1555 ;; UNIX symbol tables might have tabs in them, and tabs are
1556 ;; not in Common Lisp STANDARD-CHAR, so there seems to be no
1557 ;; nice portable way to deal with them within Lisp, alas.
1558 ;; Fortunately, it's easy to use UNIX command line tools like
1559 ;; sed to remove the problem, so it's not too painful for us
1560 ;; to push responsibility for converting tabs to spaces out to
1561 ;; the caller.
1562 ;;
1563 ;; Other non-STANDARD-CHARs are problematic for the same reason.
1564 ;; Make sure that there aren't any..
1567 line)))
1570 ch
1571 line)))
1576 ;; KLUDGE: It's too messy to try to understand all
1577 ;; possible output from nm, so we just punt the lines we
1578 ;; don't recognize. We realize that there's some chance
1579 ;; that might get us in trouble someday, so we warn
1580 ;; about it.
1593 name old-value value)))
1618 code-object
1619 offset
1620 &optional
1627 ;; FIXME: Should this be ERROR instead of WARN?
1630 value))
1632 ;;; The x86 port needs to store code fixups along with code objects if
1633 ;;; they are to be moved, so fixups for code objects in the dynamic
1634 ;;; heap need to be noted.
1640 ;; If CODE-OBJECT might be moved
1642 dynamic-core-space-id)
1643 ;; FIXME: pushed thing should be a structure, not just a list
1657 code-object
1667 ;;; Given a pointer to a code object and an offset relative to the
1668 ;;; tail of the code object's header, return an offset relative to the
1669 ;;; (beginning of the) code object.
1670 ;;;
1671 ;;; FIXME: It might be clearer to reexpress
1672 ;;; (LET ((X (CALC-OFFSET CODE-OBJECT OFFSET0))) ..)
1673 ;;; as
1674 ;;; (LET ((X (+ OFFSET0 (CODE-OBJECT-HEADER-N-BYTES CODE-OBJECT)))) ..).
1682 result))
1685 do-cold-fixup))
1690 offset-within-code-object))
1694 ;; See CMU CL source for other formerly-supported architectures
1695 ;; (and note that you have to rewrite them to use BVREF-X
1696 ;; instead of SAP-REF).
1697 (:alpha
1699 (:jmp-hint
1701 (:bits-63-48
1709 (:bits-47-32
1716 (:ldah
1722 (:lda
1727 (:hppa
1729 (:load
1734 (:load-short
1741 (:hi
1750 (:branch
1757 (:mips
1759 (:jump
1764 (:lui
1769 (:addi
1774 ;; FIXME: PowerPC Fixups are not fully implemented. The bit
1775 ;; here starts to set things up to work properly, but there
1776 ;; needs to be corresponding code in ppc-vm.lisp
1777 (:ppc
1779 (:ba
1783 (:ha
1791 (:l
1797 (:sparc
1799 (:call
1801 (:sethi
1806 (:add
1813 gspace-byte-offset))
1817 (+ gspace-byte-address
1820 (:absolute
1823 fixed-up)
1824 ;; comment from CMU CL sources:
1825 ;;
1826 ;; Note absolute fixups that point within the object.
1827 ;; KLUDGE: There seems to be an implicit assumption in
1828 ;; the old CMU CL code here, that if it doesn't point
1829 ;; before the object, it must point within the object
1830 ;; (not beyond it). It would be good to add an
1831 ;; explanation of why that's true, or an assertion that
1832 ;; it's really true, or both.
1835 after-header
1836 value
1837 kind))))
1840 gspace-byte-address
1841 gspace-byte-offset
1844 fixed-up)
1845 ;; Note relative fixups that point outside the code
1846 ;; object, which is to say all relative fixups, since
1847 ;; relative addressing within a code object never needs
1848 ;; a fixup.
1850 after-header
1851 value
1852 kind))))))))
1862 ;;; *COLD-FOREIGN-SYMBOL-TABLE* becomes *!INITIAL-FOREIGN-SYMBOLS* in
1863 ;;; the core. When the core is loaded, !LOADER-COLD-INIT uses this to
1864 ;;; create *STATIC-FOREIGN-SYMBOLS*, which the code in
1865 ;;; target-load.lisp refers to.
1871 result))
1878 result))
1881 \f
1882 ;;;; general machinery for cold-loading FASL files
1884 ;;; FOP functions for cold loading
1886 ;; We start out with a copy of the ordinary *FOP-FUNS*. The ones
1887 ;; which aren't appropriate for cold load will be destructively
1888 ;; modified.
1893 ;;; Cause a fop to have a special definition for cold load.
1894 ;;;
1895 ;;; This is similar to DEFINE-FOP, but unlike DEFINE-FOP, this version
1896 ;;; (1) looks up the code for this name (created by a previous
1897 ;; DEFINE-FOP) instead of creating a code, and
1898 ;;; (2) stores its definition in the *COLD-FOP-FUNS* vector,
1899 ;;; instead of storing in the *FOP-FUNS* vector.
1911 forms))
1925 ;;; Cause a fop to be undefined in cold load.
1930 ;;; COLD-LOAD loads stuff into the core image being built by calling
1931 ;;; LOAD-AS-FASL with the fop function table rebound to a table of cold
1932 ;;; loading functions.
1934 #!+sb-doc
1935 "Load the file named by FILENAME into the cold load image being built."
1943 \f
1944 ;;;; miscellaneous cold fops
1973 layout
1988 result))
1999 ;; If a layout of this name has been defined already
2001 ;; Enforce consistency between the previous definition and the
2002 ;; current definition, then return the previous definition.
2004 ;; FIXME: This would be more maintainable if we used
2005 ;; DEFSTRUCT (:TYPE LIST) to define COLD-LAYOUT. -- WHN 19990825
2007 old-name
2008 old-length
2009 old-inherits-list
2010 old-depthoid
2011 old-nuntagged)
2012 old
2024 time length was ~S and current length is ~S"
2025 name
2026 length
2027 old-length))
2030 time inherits were ~S~%~
2031 and current inherits are ~S"
2032 name
2033 inherits-list
2034 old-inherits-list))
2037 time inheritance depthoid was ~S and current inheritance~%~
2038 depthoid is ~S"
2039 name
2040 depthoid
2041 old-depthoid))
2044 time number of untagged slots was ~S and is currently ~S"
2045 name
2046 nuntagged
2047 old-nuntagged)))
2048 old-layout-descriptor)
2049 ;; Make a new definition from scratch.
2051 nuntagged-des))))
2052 \f
2053 ;;;; cold fops for loading symbols
2055 ;;; Load a symbol SIZE characters long from *FASL-INPUT-STREAM* and
2056 ;;; intern that symbol in PACKAGE.
2088 \f
2089 ;;;; cold fops for loading lists
2091 ;;; Make a list of the top LENGTH things on the fop stack. The last
2092 ;;; cdr of the list is set to LAST.
2135 \f
2136 ;;;; cold fops for loading vectors
2145 #!+sb-unicode
2155 size
2163 result))
2196 :start start
2198 result))
2205 len
2212 :start start
2214 result))
2242 (* total-elements
2250 dim)))
2254 result))
2256 \f
2257 ;;;; cold fops for loading numbers
2261 ;; Invoke the ordinary warm version of this fop to push the
2262 ;; number.
2264 ;; Replace the warm fop result with the cold image of the warm
2265 ;; fop result.
2286 \f
2287 ;;;; cold fops for calling (or not calling)
2321 \f
2322 ;;;; cold fops for fixing up circularities
2338 (+ idx
2349 ;;; In the original CMUCL code, this actually explicitly declared PUSHP
2350 ;;; to be T, even though that's what it defaults to in DEFINE-COLD-FOP.
2357 obj)
2358 \f
2359 ;;;; cold fops for loading code objects and functions
2361 ;;; the names of things which have had COLD-FSET used on them already
2362 ;;; (used to make sure that we don't try to statically link a name to
2363 ;;; more than one definition)
2365 ;; This can't be an EQL hash table because names can be conses, e.g.
2366 ;; (SETF CAR).
2384 ;;; Setting this variable shows what code looks like before any
2385 ;;; fixups (or function headers) are applied.
2388 ;;; FIXME: The logic here should be converted into a function
2389 ;;; COLD-CODE-FOP-GUTS (NCONST CODE-SIZE) called by DEFINE-COLD-FOP
2390 ;;; FOP-CODE and DEFINE-COLD-FOP FOP-SMALL-CODE, so that
2391 ;;; variable-capture nastiness like (LET ((NCONST ,NCONST) ..) ..)
2392 ;;; doesn't keep me awake at night.
2399 ;; Note: we round the number of constants up to ensure
2400 ;; that the code vector will be properly aligned.
2405 code-size)
2419 raw-header-n-words
2429 :start start
2431 #!+sb-show
2434 "~&/raw code from code-fop ~W ~W:~%"
2435 nconst
2436 code-size)
2440 "/#X~8,'0x: #X~8,'0x~%"
2443 des)))
2464 offset
2476 ;; KLUDGE: Wiring decisions like this in at
2477 ;; this level ("if it's an x86") instead of a
2478 ;; higher level of abstraction ("if it has such
2479 ;; and such relocation peculiarities (which
2480 ;; happen to be confined to the x86)") is bad.
2481 ;; It would be nice if the code were instead
2482 ;; conditional on some more descriptive
2483 ;; feature, :STICKY-CODE or
2484 ;; :LOAD-GC-INTERACTION or something.
2485 ;;
2486 ;; FIXME: The X86 definition of the function
2487 ;; self slot breaks everything object.tex says
2488 ;; about it. (As far as I can tell, the X86
2489 ;; definition makes it a pointer to the actual
2490 ;; code instead of a pointer back to the object
2491 ;; itself.) Ask on the mailing list whether
2492 ;; this is documented somewhere, and if not,
2493 ;; try to reverse engineer some documentation.
2495 ;; a pointer back to the function object, as
2496 ;; described in CMU CL
2497 ;; src/docs/internals/object.tex
2498 fn
2500 ;; KLUDGE: a pointer to the actual code of the
2501 ;; object, as described nowhere that I can find
2502 ;; -- WHN 19990907
2507 ;; FIXME: We should mask out the type
2508 ;; bits, not assume we know what they
2509 ;; are and subtract them out this way.
2516 fn))
2527 code-object))
2529 #!+linkage-table
2544 ;; Note: we round the number of constants up to ensure that
2545 ;; the code vector will be properly aligned.
2550 length)
2568 :start start
2570 des))
2577 routine
2579 des))
2587 code-object))
2595 code-object))
2596 \f
2597 ;;;; emitting C header file
2607 "(As of sbcl-0.8.14, it came from WRITE-CONFIG-H in genesis.lisp.)"
2608 nil
2609 "This file contains low-level information about the"
2610 "internals of a particular version and configuration"
2611 "of SBCL. It is used by the C compiler to create a runtime"
2612 "support environment, an executable program in the host"
2613 "operating system's native format, which can then be used to"
2614 "load and run 'core' files, which are basically programs"
2623 string))))
2629 ;; propagating *SHEBANG-FEATURES* into the Makefiles
2636 ;; propagating *SHEBANG-FEATURES* into C-level #define's
2642 ;; and miscellaneous constants
2645 "#define SBCL_VERSION_STRING ~S~%"
2656 ;; writing entire families of named constants
2659 ;; were automatically propagated
2660 ;; into the runtime.
2661 "SB!VM"
2662 ;; In SBCL, we also propagate various
2663 ;; magic numbers related to file format,
2664 ;; which live here instead of SB!VM.
2672 priority
2675 constants))
2676 ;; machinery for old-style CMU CL Lisp-to-C
2677 ;; arbitrary renaming, being phased out in favor of
2678 ;; the newer systematic RECORD-WITH-TRANSLATED-NAME
2679 ;; renaming
2682 'simple-string
2683 prefix
2685 priority))
2692 priority)))
2693 ;; machinery for new-style SBCL Lisp-to-C naming
2699 suffixes)
2711 ;; KLUDGE: these constants are sort of important, but there's no
2712 ;; pleasing way to inform the code above about them. So we fake
2713 ;; it for now. nikodemus on #lisp (2004-08-09) suggested simply
2714 ;; exporting every numeric constant from SB!VM; that would work,
2715 ;; but the C runtime would have to be altered to use Lisp-like names
2716 ;; rather than the munged names currently exported. --njf, 2004-08-09
2724 nil)
2725 constants))
2726 ;; One more symbol that doesn't fit into the code above.
2729 9
2731 nil)
2732 constants))
2747 ;; KLUDGE: We're dumping two different kinds of
2748 ;; values here, (1) small codes and (2) machine
2749 ;; addresses. The small codes can be dumped as bare
2750 ;; integer values. The large machine addresses might
2751 ;; cause problems if they're large and represented
2752 ;; as (signed) C integers, so we want to force them
2753 ;; to be unsigned by appending an U to the
2754 ;; literal. We can't dump all the values using the
2755 ;; literal-U syntax, since the assembler doesn't
2756 ;; support that syntax and some of the small
2757 ;; constants can be used in assembler files.
2766 value)
2770 ;; writing information about internal errors
2774 ;; FIXME: this UNLESS should go away (see also FIXME in
2775 ;; interr.lisp) -- APD, 2002-03-05
2779 i)))))
2782 ;; I'm not really sure why this is in SB!C, since it seems
2783 ;; conceptually like something that belongs to SB!VM. In any case,
2784 ;; it's needed C-side.
2789 ;; FIXME: The SPARC has a PSEUDO-ATOMIC-TRAP that differs between
2790 ;; platforms. If we export this from the SB!VM package, it gets
2791 ;; written out as #define trap_PseudoAtomic, which is confusing as
2792 ;; the runtime treats trap_ as the prefix for illegal instruction
2793 ;; type things. We therefore don't export it, but instead do
2794 #!+sparc
2797 "#define PSEUDO_ATOMIC_TRAP ~D /* 0x~:*~X */~%"
2800 ;; possibly this is another candidate for a rename (to
2801 ;; pseudo-atomic-trap-number or pseudo-atomic-magic-constant
2802 ;; [possibly applicable to other platforms])
2818 ;; writing primitive object layouts
2821 "struct ~A {~%"
2864 ;; FIXME: It would be nice to use longer names than NIL and
2865 ;; (particularly) T in #define statements.
2867 ;; FIXME: It would be nice not to need to strip anything
2868 ;; that doesn't get stripped always by C-SYMBOL-NAME.
2871 ;; We actually ran GENESIS, use the real value.
2873 ;; We didn't run GENESIS, so guess at the address.
2879 \f
2880 ;;;; writing map file
2882 ;;; Write a map file describing the cold load. Some of this
2883 ;;; information is subject to change due to relocating GC, but even so
2884 ;;; it can be very handy when attempting to troubleshoot the early
2885 ;;; stages of cold load.
2904 funs)))))
2912 "~%~|
2913 (a note about initially undefined function references: These functions
2914 are referred to by code which is installed by GENESIS, but they are not
2915 installed by GENESIS. This is not necessarily a problem; functions can
2916 be defined later, by cold init toplevel forms, or in files compiled and
2917 loaded at warm init, or elsewhere. As long as they are defined before
2918 they are called, everything should be OK. Things are also OK if the
2919 cross-compiler knew their inline definition and used that everywhere
2920 that they were called before the out-of-line definition is installed,
2921 as is fairly common for structure accessors.)
2939 \f
2940 ;;;; writing core file
2945 ;;; magic numbers to identify entries in a core file
2946 ;;;
2947 ;;; (In case you were wondering: No, AFAIK there's no special magic about
2948 ;;; these which requires them to be in the 38xx range. They're just
2949 ;;; arbitrary words, tested not for being in a particular range but just
2950 ;;; for equality. However, if you ever need to look at a .core file and
2951 ;;; figure out what's going on, it's slightly convenient that they're
2952 ;;; all in an easily recognizable range, and displacing the range away from
2953 ;;; zero seems likely to reduce the chance that random garbage will be
2954 ;;; misinterpreted as a .core file.)
2967 (:little-endian
2970 (:big-endian
2974 num)
2992 "writing ~S byte~:P [~S page~:P] from ~S~%"
2993 total-bytes
2994 pages
2995 gspace)
2998 ;; Note: It is assumed that the GSPACE allocation routines always
2999 ;; allocate whole pages (of size *target-page-size*) and that any
3000 ;; empty gspace between the free pointer and the end of page will
3001 ;; be zero-filled. This will always be true under Mach on machines
3002 ;; where the page size is equal. (RT is 4K, PMAX is 4K, Sun 3 is
3003 ;; 8K).
3010 ;; Write part of a (new) directory entry which looks like this:
3011 ;; GSPACE IDENTIFIER
3012 ;; WORD COUNT
3013 ;; DATA PAGE
3014 ;; ADDRESS
3015 ;; PAGE COUNT
3027 ;;; Create a core file created from the cold loaded image. (This is
3028 ;;; the "initial core file" because core files could be created later
3029 ;;; by executing SAVE-LISP in a running system, perhaps after we've
3030 ;;; added some functionality to the system.)
3038 "[building initial core file in ~S: ~%"
3039 filenamestring)
3047 ;; Write the magic number.
3050 ;; Write the Version entry.
3055 ;; Write the build ID.
3062 ;; Write length of build ID record: BUILD-ID-CORE-ENTRY-TYPE-CODE
3063 ;; word, this length word, and one word for each char of BUILD-ID.
3066 ;; (We write each character as a word in order to avoid
3067 ;; having to think about word alignment issues in the
3068 ;; sbcl-0.7.8 version of coreparse.c.)
3071 ;; Write the New Directory entry header.
3079 ;; Write the initial function.
3087 "~&/(DESCRIPTOR-BITS INITIAL-FUN)=#X~X~%"
3091 ;; Write the End entry.
3099 \f
3100 ;;;; the actual GENESIS function
3102 ;;; Read the FASL files in OBJECT-FILE-NAMES and produce a Lisp core,
3103 ;;; and/or information about a Lisp core, therefrom.
3104 ;;;
3105 ;;; input file arguments:
3106 ;;; SYMBOL-TABLE-FILE-NAME names a UNIX-style .nm file *with* *any*
3107 ;;; *tab* *characters* *converted* *to* *spaces*. (We push
3108 ;;; responsibility for removing tabs out to the caller it's
3109 ;;; trivial to remove them using UNIX command line tools like
3110 ;;; sed, whereas it's a headache to do it portably in Lisp because
3111 ;;; #\TAB is not a STANDARD-CHAR.) If this file is not supplied,
3112 ;;; a core file cannot be built (but a C header file can be).
3113 ;;;
3114 ;;; output files arguments (any of which may be NIL to suppress output):
3115 ;;; CORE-FILE-NAME gets a Lisp core.
3116 ;;; C-HEADER-FILE-NAME gets a C header file, traditionally called
3117 ;;; internals.h, which is used by the C compiler when constructing
3118 ;;; the executable which will load the core.
3119 ;;; MAP-FILE-NAME gets (?) a map file. (dunno about this -- WHN 19990815)
3120 ;;;
3121 ;;; FIXME: GENESIS doesn't belong in SB!VM. Perhaps in %KERNEL for now,
3122 ;;; perhaps eventually in SB-LD or SB-BOOT.
3124 object-file-names
3125 symbol-table-file-name
3126 core-file-name
3127 map-file-name
3128 c-header-dir-name)
3131 "~&beginning GENESIS, ~A~%"
3133 ;; Note: This output summarizing what we're doing is
3134 ;; somewhat telegraphic in style, not meant to imply that
3135 ;; we're not e.g. also creating a header file when we
3136 ;; create a core.
3147 ;; Now that we've successfully read our only input file (by
3148 ;; loading the symbol table, if any), it's a good time to ensure
3149 ;; that there'll be someplace for our output files to go when
3150 ;; we're done.
3157 ;; (This shouldn't matter in normal use, since GENESIS normally
3158 ;; only runs once in any given Lisp image, but it could reduce
3159 ;; confusion if we ever experiment with running, tweaking, and
3160 ;; rerunning genesis interactively.)
3170 read-only-core-space-id
3173 static-core-space-id
3176 dynamic-core-space-id
3182 0
3188 ;; Prepare for cold load.
3193 ;; Initialize the *COLD-SYMBOLS* system with the information
3194 ;; from package-data-list.lisp-expr and
3195 ;; common-lisp-exports.lisp-expr.
3196 ;;
3197 ;; Why do things this way? Historically, the *COLD-SYMBOLS*
3198 ;; machinery was designed and implemented in CMU CL long before
3199 ;; I (WHN) ever heard of CMU CL. It dumped symbols and packages
3200 ;; iff they were used in the cold image. When I added the
3201 ;; package-data-list.lisp-expr mechanism, the idea was to
3202 ;; centralize all information about packages and exports. Thus,
3203 ;; it was the natural place for information even about packages
3204 ;; (such as SB!PCL and SB!WALKER) which aren't used much until
3205 ;; after cold load. This didn't quite match the CMU CL approach
3206 ;; of filling *COLD-SYMBOLS* with symbols which appear in the
3207 ;; cold image and then dumping only those symbols. By explicitly
3208 ;; putting all the symbols from package-data-list.lisp-expr and
3209 ;; from common-lisp-exports.lisp-expr into *COLD-SYMBOLS* here,
3210 ;; we feed our centralized symbol information into the old CMU
3211 ;; CL code without having to change the old CMU CL code too
3212 ;; much. (And the old CMU CL code is still useful for making
3213 ;; sure that the appropriate keywords and internal symbols end
3214 ;; up interned in the target Lisp, which is good, e.g. in order
3215 ;; to make &KEY arguments work right and in order to make
3216 ;; BACKTRACEs into target Lisp system code be legible.)
3231 ;; Make sure that information about the association
3232 ;; between PACKAGE and the symbol named NAME gets
3233 ;; recorded in the cold-intern system or (as a
3234 ;; convenience when dealing with the tree structure
3235 ;; allowed in the PACKAGE-DATA-EXPORTS slot) do
3236 ;; nothing if NAME is NIL.
3247 ;; Cold load.
3252 ;; Tidy up loose ends left by cold loading. ("Postpare from cold load?")
3260 ;; Tell the target Lisp how much stuff we've allocated.
3263 0
3267 0
3271 ;; Write results to files.
3272 ;;
3273 ;; FIXME: I dislike this approach of redefining
3274 ;; *STANDARD-OUTPUT* instead of putting the new stream in a
3275 ;; lexical variable, and it's annoying to have WRITE-MAP (to
3276 ;; *STANDARD-OUTPUT*) not be parallel to WRITE-INITIAL-CORE-FILE
3277 ;; (to a stream explicitly passed as an argument).
3286 t
3287 "#ifndef SBCL_GENESIS_~A~%#define SBCL_GENESIS_~A 1~%"
3288 n n))
3289 ,@body
3291 "#endif /* SBCL_GENESIS_~A */~%"
3314 layout