| blob | af7bb4f052e0f3628ea116f303a20a0abec70dee |
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
92 ;;; a big vector, implemented as a vector of SMALLVECs
93 ;;;
94 ;;; KLUDGE: This implementation seems portable enough for our
95 ;;; purposes, since realistically every modern implementation is
96 ;;; likely to support vectors of at least 2^16 elements. But if you're
97 ;;; masochistic enough to read this far into the contortions imposed
98 ;;; on us by ANSI and the Lisp community, for daring to use the
99 ;;; abstraction of a large linearly addressable memory space, which is
100 ;;; after all only directly supported by the underlying hardware of at
101 ;;; least 99% of the general-purpose computers in use today, then you
102 ;;; may be titillated to hear that in fact this code isn't really
103 ;;; portable, because as of sbcl-0.7.4 we need somewhat more than
104 ;;; 16Mbytes to represent a core, and ANSI only guarantees that
105 ;;; ARRAY-DIMENSION-LIMIT is not less than 1024. -- WHN 2002-06-13
109 ;;; analogous to SVREF, but into a BIGVEC
115 inner-index)))
121 inner-index)
122 new-value)))
124 ;;; analogous to LENGTH, but for a BIGVEC
125 ;;;
126 ;;; the length of BIGVEC, measured in the number of BVREFable bytes it
127 ;;; can hold
132 ;;; analogous to WRITE-SEQUENCE, but for a BIGVEC
136 stream)))
138 ;;; analogous to READ-SEQUENCE-OR-DIE, but for a BIGVEC
144 ;;; Grow BIGVEC (exponentially, so that large increases in size have
145 ;;; asymptotic logarithmic cost per byte).
157 new-outer-vector))
158 bigvec)
159 \f
160 ;;;; looking up bytes and multi-byte values in a BIGVEC (considering
161 ;;;; it as an image of machine memory on the cross-compilation target)
163 ;;; BVREF-32 and friends. These are like SAP-REF-n, except that
164 ;;; instead of a SAP we use a BIGVEC.
176 (+ byte-index
181 append
186 append
203 ;; lispobj-sized word, whatever that may be
204 ;; hopefully nobody ever wants a 128-bit SBCL...
219 \f
220 ;;;; representation of spaces in the core
222 ;;; If there is more than one dynamic space in memory (i.e., if a
223 ;;; copying GC is in use), then only the active dynamic space gets
224 ;;; dumped to core.
237 "the alignment requirement for spaces in the target.
240 ;;; a GENESIS-time representation of a memory space (e.g. read-only
241 ;;; space, dynamic space, or static space)
244 ;; name and identifier for this GSPACE
247 ;; the word address where the data will be loaded
249 ;; the data themselves. (Note that in CMU CL this was a pair of
250 ;; fields SAP and WORDS-ALLOCATED, but that wasn't very portable.)
251 ;; (And then in SBCL this was a VECTOR, but turned out to be
252 ;; unportable too, since ANSI doesn't think that arrays longer than
253 ;; 1024 (!) should needed by portable CL code...)
255 ;; the index of the next unwritten word (i.e. chunk of
256 ;; SB!VM:N-WORD-BYTES bytes) in BYTES, or equivalently the number of
257 ;; words actually written in BYTES. In order to convert to an actual
258 ;; index into BYTES, thus must be multiplied by SB!VM:N-WORD-BYTES.
271 byte-address
272 target-space-alignment))
274 :identifier identifier
276 \f
277 ;;;; representation of descriptors
280 (:constructor make-descriptor
283 ;; the GSPACE that this descriptor is allocated in, or NIL if not set yet.
285 ;; the offset in words from the start of GSPACE, or NIL if not set yet
287 ;; the high and low halves of the descriptor
288 ;;
289 ;; KLUDGE: Judging from the comments in genesis.lisp of the CMU CL
290 ;; old-rt compiler, this split dates back from a very early version
291 ;; of genesis where 32-bit integers were represented as conses of
292 ;; two 16-bit integers. In any system with nice (UNSIGNED-BYTE 32)
293 ;; structure slots, like CMU CL >= 17 or any version of SBCL, there
294 ;; seems to be no reason to persist in this. -- WHN 19990917
295 high
296 low)
308 "for fixnum: ~W"
311 unsigned))))
319 "for other immediate: #X~X, type #b~8,'0B"
324 "for pointer: #X~X, lowtag #b~3,'0B, ~A"
327 lowtag
333 ;;; Return a descriptor for a block of LENGTH bytes out of GSPACE. The
334 ;;; free word index is boosted as necessary, and if additional memory
335 ;;; is needed, we grow the GSPACE. The descriptor returned is a
336 ;;; pointer of type LOWTAG.
342 ;; Grow GSPACE as necessary until it's big enough to handle
343 ;; NEW-FREE-WORD-INDEX.
348 ;; Now that GSPACE is big enough, we can meaningfully grab a chunk of it.
357 lowtag)
358 gspace
359 old-free-word-index))))
362 #!+sb-doc
363 "the lowtag bits for DES"
373 ;; KLUDGE: The (- SB!VM:N-WORD-BITS 2) term here looks right to
374 ;; me, and it works, but in CMU CL it was (1- SB!VM:N-WORD-BITS),
375 ;; and although that doesn't make sense for me, or work for me,
376 ;; it's hard to see how it could have been wrong, since CMU CL
377 ;; genesis worked. It would be nice to understand how this came
378 ;; to be.. -- WHN 19990901
384 ;; Extract an (unsigned-byte 32), from either its fixnum or bignum
385 ;; representation.
392 ;;; common idioms
398 ;;; If DESCRIPTOR-GSPACE is already set, just return that. Otherwise,
399 ;;; figure out a GSPACE which corresponds to DES, set it into
400 ;;; (DESCRIPTOR-GSPACE DES), set a consistent value into
401 ;;; (DESCRIPTOR-WORD-OFFSET DES), and return the GSPACE.
406 ;; gspace wasn't set, now we have to search for it.
411 ;; Non-pointer objects don't have a gspace.
420 ;; Bounds-check the descriptor against the allocated area
421 ;; within each gspace.
422 ;;
423 ;; Most of the faffing around in here involving ash and
424 ;; various computed shift counts is due to the high/low
425 ;; split representation of the descriptor bits and an
426 ;; apparent disinclination to create intermediate values
427 ;; larger than a target fixnum.
428 ;;
429 ;; This code relies on the fact that GSPACEs are aligned
430 ;; such that the descriptor-low-bits low bits are zero.
436 ;; Update the descriptor with the correct gspace and the
437 ;; offset within the gspace and return the gspace.
442 descriptor-low-bits)))
452 descriptor-low-bits))))
466 type)))
473 offset)
474 type))
478 \f
479 ;;;; miscellaneous variables and other noise
481 ;;; a numeric value to be returned for undefined foreign symbols, or NIL if
482 ;;; undefined foreign symbols are to be treated as an error.
483 ;;; (In the first pass of GENESIS, needed to create a header file before
484 ;;; the C runtime can be built, various foreign symbols will necessarily
485 ;;; be undefined, but we don't need actual values for them anyway, and
486 ;;; we can just use 0 or some other placeholder. In the second pass of
487 ;;; GENESIS, all foreign symbols should be defined, so any undefined
488 ;;; foreign symbol is a problem.)
489 ;;;
490 ;;; KLUDGE: It would probably be cleaner to rewrite GENESIS so that it
491 ;;; never tries to look up foreign symbols in the first place unless
492 ;;; it's actually creating a core file (as in the second pass) instead
493 ;;; of using this hack to allow it to go through the motions without
494 ;;; causing an error. -- WHN 20000825
497 ;;; a handle on the trap object
499 ;; was: (make-other-immediate-descriptor 0 sb!vm:unbound-marker-widetag)
501 ;;; a handle on the NIL object
504 ;;; the head of a list of TOPLEVEL-THINGs describing stuff to be done
505 ;;; when the target Lisp starts up
506 ;;;
507 ;;; Each TOPLEVEL-THING can be a function to be executed or a fixup or
508 ;;; loadtime value, represented by (CONS KEYWORD ..). The FILENAME
509 ;;; tells which fasl file each list element came from, for debugging
510 ;;; purposes.
513 ;;; the head of a list of DEBUG-SOURCEs which need to be patched when
514 ;;; the cold core starts up
517 ;;; the name of the object file currently being cold loaded (as a string, not a
518 ;;; pathname), or NIL if we're not currently cold loading any object file
521 \f
522 ;;;; miscellaneous stuff to read and write the core memory
524 ;;; FIXME: should be DEFINE-MODIFY-MACRO
526 #!+sb-doc
527 "Push THING onto the given cold-load LIST."
532 #!+sb-doc
533 "Return the value which is displaced by INDEX words from ADDRESS."
543 #!+sb-doc
544 "Return the value at ADDRESS."
547 ;;; (Note: In CMU CL, this function expected a SAP-typed ADDRESS
548 ;;; value, instead of the object-and-offset we use here.)
550 note-load-time-value-reference))
564 #!+sb-doc
565 "Write VALUE displaced INDEX words from ADDRESS."
571 value)
580 #!+sb-doc
581 "Write VALUE (a DESCRIPTOR) at ADDRESS (also a DESCRIPTOR)."
583 \f
584 ;;;; allocating images of primitive objects in the cold core
586 ;;; There are three kinds of blocks of memory in the type system:
587 ;;; * Boxed objects (cons cells, structures, etc): These objects have no
588 ;;; header as all slots are descriptors.
589 ;;; * Unboxed objects (bignums): There is a single header word that contains
590 ;;; the length.
591 ;;; * Vector objects: There is a header word with the type, then a word for
592 ;;; the length, then the data.
594 #!+sb-doc
595 "Allocate LENGTH words in GSPACE and return a new descriptor of type LOWTAG
596 pointing to them."
599 #!+sb-doc
600 "Allocate LENGTH units of ELEMENT-BITS bits plus a header word in GSPACE and
601 return an ``other-pointer'' descriptor to them. Initialize the header word
602 with the resultant length and TYPE."
610 type))
611 des))
613 #!+sb-doc
614 "Allocate LENGTH units of ELEMENT-BITS size plus a header plus a length slot in
615 GSPACE and return an ``other-pointer'' descriptor to them. Initialize the
616 header word with TYPE and the length slot with LENGTH."
617 ;; FIXME: Here and in ALLOCATE-UNBOXED-OBJECT, BYTES is calculated using
618 ;; #'/ instead of #'CEILING, which seems wrong.
627 des))
628 \f
629 ;;;; copying simple objects into the cold core
632 #!+sb-doc
633 "Copy STRING (which must only contain STANDARD-CHARs) into the cold
634 core and return a descriptor to it."
635 ;; (Remember that the system convention for storage of strings leaves an
636 ;; extra null byte at the end to aid in call-out to C.)
653 des))
656 #!+sb-doc
657 "Copy a bignum to the cold core."
661 words
668 ;; FIXME: Shouldn't this be a fatal error?
670 words n remainder)))
675 word)))))
676 handle))
679 #!+sb-doc
680 "Makes a number pair of TYPE (ratio or complex) and fills it in."
684 des))
694 (:little-endian
697 (:big-endian
704 ;; Just guessing.
708 address))
713 ;; 64-bit platforms have immediate single-floats.
725 des))
742 des))
754 ;;; Copy the given number to the core.
766 #!+long-float
784 des))
786 ;;; Allocate a cons cell in GSPACE and fill it in with CAR and CDR.
791 dest))
793 ;;; Make a simple-vector on the target that holds the specified
794 ;;; OBJECTS, and return its descriptor.
802 result))
803 \f
804 ;;;; symbol magic
806 ;;; FIXME: This should be a &KEY argument of ALLOCATE-SYMBOL.
809 ;;; Allocate (and initialize) a symbol.
825 symbol))
827 ;;; Set the cold symbol value of SYMBOL-OR-SYMBOL-DES, which can be either a
828 ;;; descriptor of a cold symbol or (in an abbreviation for the
829 ;;; most common usage pattern) an ordinary symbol, which will be
830 ;;; automatically cold-interned.
837 \f
838 ;;;; layouts and type system pre-initialization
840 ;;; Since we want to be able to dump structure constants and
841 ;;; predicates with reference layouts, we need to create layouts at
842 ;;; cold-load time. We use the name to intern layouts by, and dump a
843 ;;; list of all cold layouts in *!INITIAL-LAYOUTS* so that type system
844 ;;; initialization can find them. The only thing that's tricky [sic --
845 ;;; WHN 19990816] is initializing layout's layout, which must point to
846 ;;; itself.
848 ;;; a map from class names to lists of
849 ;;; `(,descriptor ,name ,length ,inherits ,depth)
850 ;;; KLUDGE: It would be more understandable and maintainable to use
851 ;;; DEFSTRUCT (:TYPE LIST) here. -- WHN 19990823
854 ;;; a map from DESCRIPTOR-BITS of cold layouts to the name, for inverting
855 ;;; mapping
858 ;;; FIXME: *COLD-LAYOUTS* and *COLD-LAYOUT-NAMES* should be
859 ;;; initialized by binding in GENESIS.
861 ;;; the descriptor for layout's layout (needed when making layouts)
868 ;; KLUDGE: this is a little bit sleazy, but the tricky thing is that
869 ;; structure slots don't have a terribly firm idea of their names.
870 ;; At least here if we change LAYOUT's package of definition, we
871 ;; only have to change one thing...
882 cold-layout
884 value))
886 ;;; Return a list of names created from the cold layout INHERITS data
887 ;;; in X.
898 index
903 descriptor)
904 make-cold-layout))
907 ;; KLUDGE: Why 1+? -- WHN 19990901
908 ;; header word? -- CSR 20051204
915 ;; KLUDGE: The offsets into LAYOUT below should probably be pulled out
916 ;; of the cross-compiler's tables at genesis time instead of inserted
917 ;; by hand as bare numeric constants. -- WHN ca. 19990901
919 ;; Set slot 0 = the layout of the layout.
922 ;; Don't set the CLOS hash value: done in cold-init instead.
923 ;;
924 ;; Set other slot values.
925 ;;
926 ;; leave CLASSOID uninitialized for now
938 name
945 result))
951 ;; We initially create the layout of LAYOUT itself with NIL as the LAYOUT and
952 ;; #() as INHERITS,
965 ;; Then we create the layouts that we'll need to make a correct INHERITS
966 ;; vector for the layout of LAYOUT itself..
967 ;;
968 ;; FIXME: The various LENGTH and DEPTHOID numbers should be taken from
969 ;; the compiler's tables, not set by hand.
989 so-layout
990 bso-layout)))
992 ;; ..and return to backpatch the layout of LAYOUT.
996 \f
997 ;;;; interning symbols in the cold image
999 ;;; In order to avoid having to know about the package format, we
1000 ;;; build a data structure in *COLD-PACKAGE-SYMBOLS* that holds all
1001 ;;; interned symbols along with info about their packages. The data
1002 ;;; structure is a list of sublists, where the sublists have the
1003 ;;; following format:
1004 ;;; (<make-package-arglist>
1005 ;;; <internal-symbols>
1006 ;;; <external-symbols>
1007 ;;; <imported-internal-symbols>
1008 ;;; <imported-external-symbols>
1009 ;;; <shadowing-symbols>
1010 ;;; <package-documentation>)
1011 ;;;
1012 ;;; KLUDGE: It would be nice to implement the sublists as instances of
1013 ;;; a DEFSTRUCT (:TYPE LIST). (They'd still be lists, but at least we'd be
1014 ;;; using mnemonically-named operators to access them, instead of trying
1015 ;;; to remember what THIRD and FIFTH mean, and hoping that we never
1016 ;;; need to change the list layout..) -- WHN 19990825
1018 ;;; an alist from packages to lists of that package's symbols to be dumped
1022 ;;; a map from descriptors to symbols, so that we can back up. The key
1023 ;;; is the address in the target core.
1027 ;;; sanity check for a symbol we're about to create on the target
1028 ;;;
1029 ;;; Make sure that the symbol has an appropriate package. In
1030 ;;; particular, catch the so-easy-to-make error of typing something
1031 ;;; like SB-KERNEL:%BYTE-BLT in cold sources when what you really
1032 ;;; need is SB!KERNEL:%BYTE-BLT.
1036 ;; Cold interning things in these standard packages is OK. (Cold
1037 ;; interning things in the other standard package, CL-USER, isn't
1038 ;; OK. We just use CL-USER to expose symbols whose homes are in
1039 ;; other packages. Thus, trying to cold intern a symbol whose
1040 ;; home package is CL-USER probably means that a coding error has
1041 ;; been made somewhere.)
1043 ;; Cold interning something in one of our target-code packages,
1044 ;; which are ever-so-rigorously-and-elegantly distinguished by
1045 ;; this prefix on their names, is OK too.
1047 ;; This one is OK too, since it ends up being COMMON-LISP on the
1048 ;; target.
1050 ;; Anything else looks bad. (maybe COMMON-LISP-USER? maybe an extension
1051 ;; package in the xc host? something we can't think of
1052 ;; a valid reason to cold intern, anyway...)
1053 )))
1055 ;;; like SYMBOL-PACKAGE, but safe for symbols which end up on the target
1056 ;;;
1057 ;;; Most host symbols we dump onto the target are created by SBCL
1058 ;;; itself, so that as long as we avoid gratuitously
1059 ;;; cross-compilation-unfriendly hacks, it just happens that their
1060 ;;; SYMBOL-PACKAGE in the host system corresponds to their
1061 ;;; SYMBOL-PACKAGE in the target system. However, that's not the case
1062 ;;; in the COMMON-LISP package, where we don't get to create the
1063 ;;; symbols but instead have to use the ones that the xc host created.
1064 ;;; In particular, while ANSI specifies which symbols are exported
1065 ;;; from COMMON-LISP, it doesn't specify that their home packages are
1066 ;;; COMMON-LISP, so the xc host can keep them in random packages which
1067 ;;; don't exist on the target (e.g. CLISP keeping some CL-exported
1068 ;;; symbols in the CLOS package).
1070 ;; We want to catch weird symbols like CLISP's
1071 ;; CL:FIND-METHOD=CLOS::FIND-METHOD, but we don't want to get
1072 ;; sidetracked by ordinary symbols like :CHARACTER which happen to
1073 ;; have the same SYMBOL-NAME as exports from COMMON-LISP.
1078 ;; special case, to work around possible xc host weirdness
1079 ;; in COMMON-LISP package
1081 ;; ordinary case
1085 result))))
1087 ;;; Return a handle on an interned symbol. If necessary allocate the
1088 ;;; symbol and record which package the symbol was referenced in. When
1089 ;;; we allocate the symbol, make sure we record a reference to the
1090 ;;; symbol in the home package so that the package gets set.
1092 &optional
1097 ;; Anything on the cross-compilation host which refers to the target
1098 ;; machinery through the host SB-XC package should be translated to
1099 ;; something on the target which refers to the same machinery
1100 ;; through the target COMMON-LISP package.
1108 ;; in COLD-INTERN-INFO.
1109 ;; (CAR COLD-INTERN-INFO) = descriptor of symbol
1110 ;; (CDR COLD-INTERN-INFO) = list of packages, other than symbol's
1111 ;; own package, referring to symbol
1112 ;; (*COLD-PACKAGE-SYMBOLS* and *COLD-SYMBOLS* store basically the
1113 ;; same information, but with the mapping running the opposite way.)
1138 ;;; Construct and return a value for use as *NIL-DESCRIPTOR*.
1151 1
1153 0
1157 result)
1160 result)
1163 result)
1166 ;; This is *DYNAMIC*, and DES is *STATIC*,
1167 ;; because that's the way CMU CL did it; I'm
1168 ;; not sure whether there's an underlying
1169 ;; reason. -- WHN 1990826
1173 result)
1177 result))
1179 ;;; Since the initial symbols must be allocated before we can intern
1180 ;;; anything else, we intern those here. We also set the value of T.
1182 #!+sb-doc
1183 "Initialize the cold load symbol-hacking data structures."
1185 ;; Intern the others.
1192 ;; FIXME: should be fatal
1194 symbol
1195 nil
1196 offset-found
1197 offset-wanted))))
1198 ;; Establish the value of T.
1201 ;; Establish the value of *PSEUDO-ATOMIC-BITS* so that the
1202 ;; allocation sequences that expect it to be zero upon entrance
1203 ;; actually find it to be so.
1208 ;;; a helper function for FINISH-SYMBOLS: Return a cold alist suitable
1209 ;;; to be stored in *!INITIAL-LAYOUTS*.
1225 result))))
1227 ;;; Establish initial values for magic symbols.
1228 ;;;
1229 ;;; Scan over all the symbols referenced in each package in
1230 ;;; *COLD-PACKAGE-SYMBOLS* making that for each one there's an
1231 ;;; appropriate entry in the *!INITIAL-SYMBOLS* data structure to
1232 ;;; intern it.
1235 ;; I think the point of setting these functions into SYMBOL-VALUEs
1236 ;; here, instead of using SYMBOL-FUNCTION, is that in CMU CL
1237 ;; SYMBOL-FUNCTION reduces to FDEFINITION, which is a pretty
1238 ;; hairy operation (involving globaldb.lisp etc.) which we don't
1239 ;; want to invoke early in cold init. -- WHN 2001-12-05
1240 ;;
1241 ;; FIXME: So OK, that's a reasonable reason to do something weird like
1242 ;; this, but this is still a weird thing to do, and we should change
1243 ;; the names to highlight that something weird is going on. Perhaps
1244 ;; *MAYBE-GC-FUN*, *INTERNAL-ERROR-FUN*, *HANDLE-BREAKPOINT-FUN*,
1245 ;; and *HANDLE-FUN-END-BREAKPOINT-FUN*...
1263 ;; KLUDGE: NIL punned as 0-length string.
1265 ;; don't propagate the arbitrary
1266 ;; docstring from host packages into
1267 ;; the core
1281 ;; FIXME: Add assertions here to make sure that inappropriate stuff
1282 ;; isn't being dumped:
1283 ;; * the CL-USER package
1284 ;; * the SB-COLD package
1285 ;; * any internal symbols in the CL package
1286 ;; * basically any package other than CL, KEYWORD, or the packages
1287 ;; in package-data-list.lisp-expr
1288 ;; and that the structure of the KEYWORD package (e.g. whether
1289 ;; any symbols are internal to it) matches what we want in the
1290 ;; target SBCL.
1292 ;; FIXME: It seems possible that by looking at the contents of
1293 ;; packages in the target SBCL we could find which symbols in
1294 ;; package-data-lisp.lisp-expr are now obsolete. (If I
1295 ;; understand correctly, only symbols which actually have
1296 ;; definitions or which are otherwise referred to actually end
1297 ;; up in the target packages.)
1302 cold-package))))
1307 symbol
1308 cold-package))
1330 internal-count
1331 external-count)
1332 r)
1333 ;; FIXME: It would be more space-efficient to use vectors
1334 ;; instead of lists here, and space-efficiency here would be
1335 ;; nice, since it would reduce the peak memory usage in
1336 ;; genesis and cold init.
1352 ;;; Make a cold list that can be used as the arg list to MAKE-PACKAGE in
1353 ;;; order to make a package that is similar to PKG.
1362 ;; Make the package nickname lists for the standard packages
1363 ;; be the minimum specified by ANSI, regardless of what value
1364 ;; the cross-compilation host happens to use.
1370 '())
1371 ;; For packages other than the
1372 ;; standard packages, the nickname
1373 ;; list was specified by our package
1374 ;; setup code, not by properties of
1375 ;; what cross-compilation host we
1376 ;; happened to use, and we can just
1377 ;; propagate it into the target.
1383 ;; INTERNAL-COUNT and EXTERNAL-COUNT are the number of symbols that
1384 ;; the package contains in the core. We arrange for the package
1385 ;; symbol tables to be created somewhat larger so that they don't
1386 ;; need to be rehashed so easily when additional symbols are
1387 ;; interned during the warm build.
1400 res))
1401 \f
1402 ;;;; functions and fdefinition objects
1404 ;;; a hash table mapping from fdefinition names to descriptors of cold
1405 ;;; objects
1406 ;;;
1407 ;;; Note: Since fdefinition names can be lists like '(SETF FOO), and
1408 ;;; we want to have only one entry per name, this must be an 'EQUAL
1409 ;;; hash table, not the default 'EQL.
1414 ;;; Given a cold representation of a symbol, return a warm
1415 ;;; representation.
1417 ;; Note that COLD-INTERN is responsible for keeping the
1418 ;; *COLD-SYMBOLS* table up to date, so if DES happens to refer to an
1419 ;; uninterned symbol, the code below will fail. But as long as we
1420 ;; don't need to look up uninterned symbols during bootstrapping,
1421 ;; that's OK..
1427 symbol))
1429 ;;; like CL:CAR, CL:CDR, and CL:NULL but for cold values
1440 ;;; Given a cold representation of a function name, return a warm
1441 ;;; representation.
1448 ;; Do cold (DESTRUCTURING-BIND (COLD-CAR COLD-CADR) DES ..).
1459 result))
1481 fdefn))))
1483 ;;; Handle the at-cold-init-time, fset-for-static-linkage operation
1484 ;;; requested by FOP-FSET.
1495 #!+sparc
1496 defn
1497 #!-sparc
1507 fdefn))
1519 ;; FIXME: should be fatal
1521 sym nil offset desired))))))
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.
1635 #!+x86
1638 #!+x86
1640 ;; If CODE-OBJECT might be moved
1642 dynamic-core-space-id)
1645 nil)))
1648 #!+x86
1668 ;; KLUDGE: The fixup vector is stored as the first constant,
1669 ;; not as a separately-named slot.
1672 fixup-vector))))))
1674 ;;; Given a pointer to a code object and an offset relative to the
1675 ;;; tail of the code object's header, return an offset relative to the
1676 ;;; (beginning of the) code object.
1677 ;;;
1678 ;;; FIXME: It might be clearer to reexpress
1679 ;;; (LET ((X (CALC-OFFSET CODE-OBJECT OFFSET0))) ..)
1680 ;;; as
1681 ;;; (LET ((X (+ OFFSET0 (CODE-OBJECT-HEADER-N-BYTES CODE-OBJECT)))) ..).
1689 result))
1692 do-cold-fixup))
1697 offset-within-code-object))
1701 ;; See CMU CL source for other formerly-supported architectures
1702 ;; (and note that you have to rewrite them to use BVREF-X
1703 ;; instead of SAP-REF).
1704 (:alpha
1706 (:jmp-hint
1708 (:bits-63-48
1716 (:bits-47-32
1723 (:ldah
1729 (:lda
1734 (:hppa
1736 (:load
1743 (:load11u
1750 (:load-short
1759 (:hi
1768 (:branch
1776 (:mips
1778 (:jump
1783 (:lui
1788 (:addi
1793 ;; FIXME: PowerPC Fixups are not fully implemented. The bit
1794 ;; here starts to set things up to work properly, but there
1795 ;; needs to be corresponding code in ppc-vm.lisp
1796 (:ppc
1798 (:ba
1802 (:ha
1810 (:l
1816 (:sparc
1818 (:call
1820 (:sethi
1825 (:add
1831 ;; XXX: Note that un-fixed-up is read via bvref-word, which is
1832 ;; 64 bits wide on x86-64, but the fixed-up value is written
1833 ;; via bvref-32. This would make more sense if we supported
1834 ;; :absolute64 fixups, but apparently the cross-compiler
1835 ;; doesn't dump them.
1837 gspace-byte-offset))
1841 (+ gspace-byte-address
1844 (:absolute
1847 fixed-up)
1848 ;; comment from CMU CL sources:
1849 ;;
1850 ;; Note absolute fixups that point within the object.
1851 ;; KLUDGE: There seems to be an implicit assumption in
1852 ;; the old CMU CL code here, that if it doesn't point
1853 ;; before the object, it must point within the object
1854 ;; (not beyond it). It would be good to add an
1855 ;; explanation of why that's true, or an assertion that
1856 ;; it's really true, or both.
1857 ;;
1858 ;; One possible explanation is that all absolute fixups
1859 ;; point either within the code object, within the
1860 ;; runtime, within read-only or static-space, or within
1861 ;; the linkage-table space. In all x86 configurations,
1862 ;; these areas are prior to the start of dynamic space,
1863 ;; where all the code-objects are loaded.
1864 #!+x86
1867 after-header))))
1870 gspace-byte-address
1871 gspace-byte-offset
1874 fixed-up)
1875 ;; Note relative fixups that point outside the code
1876 ;; object, which is to say all relative fixups, since
1877 ;; relative addressing within a code object never needs
1878 ;; a fixup.
1879 #!+x86
1881 after-header))))))))
1891 ;;; *COLD-FOREIGN-SYMBOL-TABLE* becomes *!INITIAL-FOREIGN-SYMBOLS* in
1892 ;;; the core. When the core is loaded, !LOADER-COLD-INIT uses this to
1893 ;;; create *STATIC-FOREIGN-SYMBOLS*, which the code in
1894 ;;; target-load.lisp refers to.
1905 result))
1911 result))
1914 \f
1915 ;;;; general machinery for cold-loading FASL files
1917 ;;; FOP functions for cold loading
1919 ;; We start out with a copy of the ordinary *FOP-FUNS*. The ones
1920 ;; which aren't appropriate for cold load will be destructively
1921 ;; modified.
1926 ;;; Cause a fop to have a special definition for cold load.
1927 ;;;
1928 ;;; This is similar to DEFINE-FOP, but unlike DEFINE-FOP, this version
1929 ;;; (1) looks up the code for this name (created by a previous
1930 ;; DEFINE-FOP) instead of creating a code, and
1931 ;;; (2) stores its definition in the *COLD-FOP-FUNS* vector,
1932 ;;; instead of storing in the *FOP-FUNS* vector.
1944 forms))
1958 ;;; Cause a fop to be undefined in cold load.
1963 ;;; COLD-LOAD loads stuff into the core image being built by calling
1964 ;;; LOAD-AS-FASL with the fop function table rebound to a table of cold
1965 ;;; loading functions.
1967 #!+sb-doc
1968 "Load the file named by FILENAME into the cold load image being built."
1976 \f
1977 ;;;; miscellaneous cold fops
2006 layout
2021 result))
2032 ;; If a layout of this name has been defined already
2034 ;; Enforce consistency between the previous definition and the
2035 ;; current definition, then return the previous definition.
2037 ;; FIXME: This would be more maintainable if we used
2038 ;; DEFSTRUCT (:TYPE LIST) to define COLD-LAYOUT. -- WHN 19990825
2040 old-name
2041 old-length
2042 old-inherits-list
2043 old-depthoid
2044 old-nuntagged)
2045 old
2057 time length was ~S and current length is ~S"
2058 name
2059 length
2060 old-length))
2063 time inherits were ~S~%~
2064 and current inherits are ~S"
2065 name
2066 inherits-list
2067 old-inherits-list))
2070 time inheritance depthoid was ~S and current inheritance~%~
2071 depthoid is ~S"
2072 name
2073 depthoid
2074 old-depthoid))
2077 time number of untagged slots was ~S and is currently ~S"
2078 name
2079 nuntagged
2080 old-nuntagged)))
2081 old-layout-descriptor)
2082 ;; Make a new definition from scratch.
2084 nuntagged-des))))
2085 \f
2086 ;;;; cold fops for loading symbols
2088 ;;; Load a symbol SIZE characters long from *FASL-INPUT-STREAM* and
2089 ;;; intern that symbol in PACKAGE.
2121 \f
2122 ;;;; cold fops for loading lists
2124 ;;; Make a list of the top LENGTH things on the fop stack. The last
2125 ;;; cdr of the list is set to LAST.
2168 \f
2169 ;;;; cold fops for loading vectors
2178 #!+sb-unicode
2188 size
2196 result))
2229 :start start
2231 result))
2238 len
2245 :start start
2247 result))
2275 (* total-elements
2283 dim)))
2287 result))
2289 \f
2290 ;;;; cold fops for loading numbers
2294 ;; Invoke the ordinary warm version of this fop to push the
2295 ;; number.
2297 ;; Replace the warm fop result with the cold image of the warm
2298 ;; fop result.
2319 \f
2320 ;;;; cold fops for calling (or not calling)
2354 \f
2355 ;;;; cold fops for fixing up circularities
2371 (+ idx
2382 ;;; In the original CMUCL code, this actually explicitly declared PUSHP
2383 ;;; to be T, even though that's what it defaults to in DEFINE-COLD-FOP.
2390 obj)
2391 \f
2392 ;;;; cold fops for loading code objects and functions
2394 ;;; the names of things which have had COLD-FSET used on them already
2395 ;;; (used to make sure that we don't try to statically link a name to
2396 ;;; more than one definition)
2398 ;; This can't be an EQL hash table because names can be conses, e.g.
2399 ;; (SETF CAR).
2421 ;;; Setting this variable shows what code looks like before any
2422 ;;; fixups (or function headers) are applied.
2425 ;;; FIXME: The logic here should be converted into a function
2426 ;;; COLD-CODE-FOP-GUTS (NCONST CODE-SIZE) called by DEFINE-COLD-FOP
2427 ;;; FOP-CODE and DEFINE-COLD-FOP FOP-SMALL-CODE, so that
2428 ;;; variable-capture nastiness like (LET ((NCONST ,NCONST) ..) ..)
2429 ;;; doesn't keep me awake at night.
2436 ;; Note: we round the number of constants up to ensure
2437 ;; that the code vector will be properly aligned.
2442 code-size)
2456 raw-header-n-words
2466 :start start
2468 #!+sb-show
2471 "~&/raw code from code-fop ~W ~W:~%"
2472 nconst
2473 code-size)
2477 "/#X~8,'0x: #X~8,'0x~%"
2480 des)))
2501 offset
2513 ;; KLUDGE: Wiring decisions like this in at
2514 ;; this level ("if it's an x86") instead of a
2515 ;; higher level of abstraction ("if it has such
2516 ;; and such relocation peculiarities (which
2517 ;; happen to be confined to the x86)") is bad.
2518 ;; It would be nice if the code were instead
2519 ;; conditional on some more descriptive
2520 ;; feature, :STICKY-CODE or
2521 ;; :LOAD-GC-INTERACTION or something.
2522 ;;
2523 ;; FIXME: The X86 definition of the function
2524 ;; self slot breaks everything object.tex says
2525 ;; about it. (As far as I can tell, the X86
2526 ;; definition makes it a pointer to the actual
2527 ;; code instead of a pointer back to the object
2528 ;; itself.) Ask on the mailing list whether
2529 ;; this is documented somewhere, and if not,
2530 ;; try to reverse engineer some documentation.
2532 ;; a pointer back to the function object, as
2533 ;; described in CMU CL
2534 ;; src/docs/internals/object.tex
2535 fn
2537 ;; KLUDGE: a pointer to the actual code of the
2538 ;; object, as described nowhere that I can find
2539 ;; -- WHN 19990907
2544 ;; FIXME: We should mask out the type
2545 ;; bits, not assume we know what they
2546 ;; are and subtract them out this way.
2553 fn))
2564 code-object))
2566 #!+linkage-table
2581 ;; Note: we round the number of constants up to ensure that
2582 ;; the code vector will be properly aligned.
2587 length)
2605 :start start
2607 des))
2614 routine
2616 des))
2624 code-object))
2632 code-object))
2633 \f
2634 ;;;; sanity checking space layouts
2637 ;;; Co-opt type machinery to check for intersections...
2649 #!+gencgc
2651 #!-gencgc
2655 #!+linkage-table
2657 \f
2658 ;;;; emitting C header file
2668 "(As of sbcl-0.8.14, it came from WRITE-CONFIG-H in genesis.lisp.)"
2669 nil
2670 "This file contains low-level information about the"
2671 "internals of a particular version and configuration"
2672 "of SBCL. It is used by the C compiler to create a runtime"
2673 "support environment, an executable program in the host"
2674 "operating system's native format, which can then be used to"
2675 "load and run 'core' files, which are basically programs"
2684 string))))
2690 ;; propagating *SHEBANG-FEATURES* into the Makefiles
2697 ;; propagating *SHEBANG-FEATURES* into C-level #define's
2703 ;; and miscellaneous constants
2706 "#define SBCL_VERSION_STRING ~S~%"
2717 ;; writing entire families of named constants
2720 ;; were automatically propagated
2721 ;; into the runtime.
2722 "SB!VM"
2723 ;; In SBCL, we also propagate various
2724 ;; magic numbers related to file format,
2725 ;; which live here instead of SB!VM.
2733 priority
2735 suffix
2737 constants))
2738 ;; machinery for old-style CMU CL Lisp-to-C
2739 ;; arbitrary renaming, being phased out in favor of
2740 ;; the newer systematic RECORD-WITH-TRANSLATED-NAME
2741 ;; renaming
2744 'simple-string
2745 prefix
2747 priority
2755 priority)))
2756 ;; machinery for new-style SBCL Lisp-to-C naming
2762 suffixes)
2774 ;; KLUDGE: these constants are sort of important, but there's no
2775 ;; pleasing way to inform the code above about them. So we fake
2776 ;; it for now. nikodemus on #lisp (2004-08-09) suggested simply
2777 ;; exporting every numeric constant from SB!VM; that would work,
2778 ;; but the C runtime would have to be altered to use Lisp-like names
2779 ;; rather than the munged names currently exported. --njf, 2004-08-09
2787 ""
2788 nil)
2789 constants))
2790 ;; One more symbol that doesn't fit into the code above.
2793 9
2795 "LU"
2796 nil)
2797 constants))
2817 ;; writing information about internal errors
2821 ;; FIXME: this UNLESS should go away (see also FIXME in
2822 ;; interr.lisp) -- APD, 2002-03-05
2826 i)))))
2829 ;; I'm not really sure why this is in SB!C, since it seems
2830 ;; conceptually like something that belongs to SB!VM. In any case,
2831 ;; it's needed C-side.
2836 ;; FIXME: The SPARC has a PSEUDO-ATOMIC-TRAP that differs between
2837 ;; platforms. If we export this from the SB!VM package, it gets
2838 ;; written out as #define trap_PseudoAtomic, which is confusing as
2839 ;; the runtime treats trap_ as the prefix for illegal instruction
2840 ;; type things. We therefore don't export it, but instead do
2841 #!+sparc
2844 "#define PSEUDO_ATOMIC_TRAP ~D /* 0x~:*~X */~%"
2847 ;; possibly this is another candidate for a rename (to
2848 ;; pseudo-atomic-trap-number or pseudo-atomic-magic-constant
2849 ;; [possibly applicable to other platforms])
2865 ;; writing primitive object layouts
2868 "struct ~A {~%"
2911 ;; FIXME: It would be nice to use longer names than NIL and
2912 ;; (particularly) T in #define statements.
2914 ;; FIXME: It would be nice not to need to strip anything
2915 ;; that doesn't get stripped always by C-SYMBOL-NAME.
2918 ;; We actually ran GENESIS, use the real value.
2920 ;; We didn't run GENESIS, so guess at the address.
2926 \f
2927 ;;;; writing map file
2929 ;;; Write a map file describing the cold load. Some of this
2930 ;;; information is subject to change due to relocating GC, but even so
2931 ;;; it can be very handy when attempting to troubleshoot the early
2932 ;;; stages of cold load.
2951 funs)))))
2959 "~%~|
2960 (a note about initially undefined function references: These functions
2961 are referred to by code which is installed by GENESIS, but they are not
2962 installed by GENESIS. This is not necessarily a problem; functions can
2963 be defined later, by cold init toplevel forms, or in files compiled and
2964 loaded at warm init, or elsewhere. As long as they are defined before
2965 they are called, everything should be OK. Things are also OK if the
2966 cross-compiler knew their inline definition and used that everywhere
2967 that they were called before the out-of-line definition is installed,
2968 as is fairly common for structure accessors.)
2986 \f
2987 ;;;; writing core file
2992 ;;; magic numbers to identify entries in a core file
2993 ;;;
2994 ;;; (In case you were wondering: No, AFAIK there's no special magic about
2995 ;;; these which requires them to be in the 38xx range. They're just
2996 ;;; arbitrary words, tested not for being in a particular range but just
2997 ;;; for equality. However, if you ever need to look at a .core file and
2998 ;;; figure out what's going on, it's slightly convenient that they're
2999 ;;; all in an easily recognizable range, and displacing the range away from
3000 ;;; zero seems likely to reduce the chance that random garbage will be
3001 ;;; misinterpreted as a .core file.)
3014 (:little-endian
3017 (:big-endian
3021 num)
3039 "writing ~S byte~:P [~S page~:P] from ~S~%"
3040 total-bytes
3041 pages
3042 gspace)
3045 ;; Note: It is assumed that the GSPACE allocation routines always
3046 ;; allocate whole pages (of size *target-page-size*) and that any
3047 ;; empty gspace between the free pointer and the end of page will
3048 ;; be zero-filled. This will always be true under Mach on machines
3049 ;; where the page size is equal. (RT is 4K, PMAX is 4K, Sun 3 is
3050 ;; 8K).
3057 ;; Write part of a (new) directory entry which looks like this:
3058 ;; GSPACE IDENTIFIER
3059 ;; WORD COUNT
3060 ;; DATA PAGE
3061 ;; ADDRESS
3062 ;; PAGE COUNT
3074 ;;; Create a core file created from the cold loaded image. (This is
3075 ;;; the "initial core file" because core files could be created later
3076 ;;; by executing SAVE-LISP in a running system, perhaps after we've
3077 ;;; added some functionality to the system.)
3085 "[building initial core file in ~S: ~%"
3086 filenamestring)
3094 ;; Write the magic number.
3097 ;; Write the Version entry.
3102 ;; Write the build ID.
3109 ;; Write length of build ID record: BUILD-ID-CORE-ENTRY-TYPE-CODE
3110 ;; word, this length word, and one word for each char of BUILD-ID.
3113 ;; (We write each character as a word in order to avoid
3114 ;; having to think about word alignment issues in the
3115 ;; sbcl-0.7.8 version of coreparse.c.)
3118 ;; Write the New Directory entry header.
3126 ;; Write the initial function.
3134 "~&/(DESCRIPTOR-BITS INITIAL-FUN)=#X~X~%"
3138 ;; Write the End entry.
3146 \f
3147 ;;;; the actual GENESIS function
3149 ;;; Read the FASL files in OBJECT-FILE-NAMES and produce a Lisp core,
3150 ;;; and/or information about a Lisp core, therefrom.
3151 ;;;
3152 ;;; input file arguments:
3153 ;;; SYMBOL-TABLE-FILE-NAME names a UNIX-style .nm file *with* *any*
3154 ;;; *tab* *characters* *converted* *to* *spaces*. (We push
3155 ;;; responsibility for removing tabs out to the caller it's
3156 ;;; trivial to remove them using UNIX command line tools like
3157 ;;; sed, whereas it's a headache to do it portably in Lisp because
3158 ;;; #\TAB is not a STANDARD-CHAR.) If this file is not supplied,
3159 ;;; a core file cannot be built (but a C header file can be).
3160 ;;;
3161 ;;; output files arguments (any of which may be NIL to suppress output):
3162 ;;; CORE-FILE-NAME gets a Lisp core.
3163 ;;; C-HEADER-FILE-NAME gets a C header file, traditionally called
3164 ;;; internals.h, which is used by the C compiler when constructing
3165 ;;; the executable which will load the core.
3166 ;;; MAP-FILE-NAME gets (?) a map file. (dunno about this -- WHN 19990815)
3167 ;;;
3168 ;;; FIXME: GENESIS doesn't belong in SB!VM. Perhaps in %KERNEL for now,
3169 ;;; perhaps eventually in SB-LD or SB-BOOT.
3171 object-file-names
3172 symbol-table-file-name
3173 core-file-name
3174 map-file-name
3175 c-header-dir-name)
3178 "~&beginning GENESIS, ~A~%"
3180 ;; Note: This output summarizing what we're doing is
3181 ;; somewhat telegraphic in style, not meant to imply that
3182 ;; we're not e.g. also creating a header file when we
3183 ;; create a core.
3194 ;; Now that we've successfully read our only input file (by
3195 ;; loading the symbol table, if any), it's a good time to ensure
3196 ;; that there'll be someplace for our output files to go when
3197 ;; we're done.
3204 ;; (This shouldn't matter in normal use, since GENESIS normally
3205 ;; only runs once in any given Lisp image, but it could reduce
3206 ;; confusion if we ever experiment with running, tweaking, and
3207 ;; rerunning genesis interactively.)
3219 read-only-core-space-id
3222 static-core-space-id
3225 dynamic-core-space-id
3232 0
3238 ;; Prepare for cold load.
3243 ;; Initialize the *COLD-SYMBOLS* system with the information
3244 ;; from package-data-list.lisp-expr and
3245 ;; common-lisp-exports.lisp-expr.
3246 ;;
3247 ;; Why do things this way? Historically, the *COLD-SYMBOLS*
3248 ;; machinery was designed and implemented in CMU CL long before
3249 ;; I (WHN) ever heard of CMU CL. It dumped symbols and packages
3250 ;; iff they were used in the cold image. When I added the
3251 ;; package-data-list.lisp-expr mechanism, the idea was to
3252 ;; centralize all information about packages and exports. Thus,
3253 ;; it was the natural place for information even about packages
3254 ;; (such as SB!PCL and SB!WALKER) which aren't used much until
3255 ;; after cold load. This didn't quite match the CMU CL approach
3256 ;; of filling *COLD-SYMBOLS* with symbols which appear in the
3257 ;; cold image and then dumping only those symbols. By explicitly
3258 ;; putting all the symbols from package-data-list.lisp-expr and
3259 ;; from common-lisp-exports.lisp-expr into *COLD-SYMBOLS* here,
3260 ;; we feed our centralized symbol information into the old CMU
3261 ;; CL code without having to change the old CMU CL code too
3262 ;; much. (And the old CMU CL code is still useful for making
3263 ;; sure that the appropriate keywords and internal symbols end
3264 ;; up interned in the target Lisp, which is good, e.g. in order
3265 ;; to make &KEY arguments work right and in order to make
3266 ;; BACKTRACEs into target Lisp system code be legible.)
3281 ;; Make sure that information about the association
3282 ;; between PACKAGE and the symbol named NAME gets
3283 ;; recorded in the cold-intern system or (as a
3284 ;; convenience when dealing with the tree structure
3285 ;; allowed in the PACKAGE-DATA-EXPORTS slot) do
3286 ;; nothing if NAME is NIL.
3297 ;; Cold load.
3302 ;; Tidy up loose ends left by cold loading. ("Postpare from cold load?")
3310 ;; Tell the target Lisp how much stuff we've allocated.
3313 0
3317 0
3321 ;; Write results to files.
3322 ;;
3323 ;; FIXME: I dislike this approach of redefining
3324 ;; *STANDARD-OUTPUT* instead of putting the new stream in a
3325 ;; lexical variable, and it's annoying to have WRITE-MAP (to
3326 ;; *STANDARD-OUTPUT*) not be parallel to WRITE-INITIAL-CORE-FILE
3327 ;; (to a stream explicitly passed as an argument).
3336 t
3337 "#ifndef SBCL_GENESIS_~A~%#define SBCL_GENESIS_~A 1~%"
3338 n n))
3339 ,@body
3341 "#endif /* SBCL_GENESIS_~A */~%"
3364 layout