+;;; Note: Mostly these values are black magic, inherited from CMU CL
+;;; without any documentation. However, there were a few explanatory
+;;; comments in the CMU CL sources:
+;;; * On Linux,
+;;; ** The space 0x08000000-0x10000000 is "C program and memory allocation".
+;;; ** The space 0x40000000-0x48000000 is reserved for shared libs.
+;;; ** The space >0xE0000000 is "C stack - Alien stack".
+;;; * On FreeBSD,
+;;; ** The space 0x0E000000-0x10000000 is "Foreign segment".
+;;; ** The space 0x20000000-0x30000000 is reserved for shared libs.
+;;; And there have been some changes since the fork from CMU CL:
+;;; * The OpenBSD port is new since the fork. We started with
+;;; the FreeBSD address map, which actually worked until the
+;;; Alpha port patches, for reasons which in retrospect are rather
+;;; mysterious. After the Alpha port patches were added, the
+;;; OpenBSD port suffered memory corruption problems. While
+;;; debugging those, it was discovered that src/runtime/trymap
+;;; failed for the control stack region #x40000000-#x47fff000.
+;;; After the control stack was moved upward out of this region
+;;; (stealing some bytes from dynamic space) the problems went
+;;; away.
+;;; * The FreeBSD STATIC-SPACE-START value was bumped up from
+;;; #x28000000 to #x30000000 when FreeBSD ld.so dynamic linking
+;;; support was added for FreeBSD ca. 20000910. This was to keep from
+;;; stomping on an address range that the dynamic libraries want to
+;;; use. (They want to use this address range even if we try to
+;;; reserve it with a call to validate() as the first operation in
+;;; main().)
+;;; * For NetBSD 2.0, the following ranges are used by normal
+;;; executables and mmap:
+;;; ** Executables are (by default) loaded at 0x08048000.
+;;; ** The break for the sbcl runtime seems to end around 0x08400000
+;;; We set read only space around 0x20000000, static
+;;; space around 0x30000000, all ending below 0x37fff000
+;;; ** ld.so and other mmap'ed stuff like shared libs start around
+;;; 0x48000000
+;;; We set dynamic space between 0x60000000 and 0x98000000
+;;; ** Bottom of the stack is typically not below 0xb0000000
+;;; FYI, this can be looked at with the "pmap" program, and if you
+;;; set the top-down mmap allocation option in the kernel (not yet
+;;; the default), all bets are totally off!
+;;; * For FreeBSD, the requirement of user and kernel space are
+;;; getting larger, and users tend to extend them.
+;;; If MAXDSIZ is extended from 512MB to 1GB, we can't use up to
+;;; around 0x50000000.
+;;; And if KVA_PAGES is extended from 1GB to 1.5GB, we can't use
+;;; down to around 0xA0000000.
+;;; So we use 0x58000000--0x98000000 for dynamic space.
+;;; * OpenBSD address space changes for W^X as well as malloc()
+;;; randomization made the old addresses unsafe.
+;;; ** By default (linked without -Z option):
+;;; The executable's text segment starts at #x1c000000 and the
+;;; data segment MAXDSIZ bytes higher, at #x3c000000. Shared
+;;; library text segments start randomly between #x00002000 and
+;;; #x10002000, with the data segment MAXDSIZ bytes after that.
+;;; ** If the -Z linker option is used:
+;;; The executable's text and data segments simply start at
+;;; #x08048000, data immediately following text. Shared library
+;;; text and data is placed as if allocated by malloc().
+;;; ** In both cases, the randomized range for malloc() starts
+;;; MAXDSIZ bytes after the end of the data segment (#x48048000
+;;; with -Z, #x7c000000 without), and extends 256 MB.
+;;; ** The read only, static, and linkage table spaces should be
+;;; safe with and without -Z if they are located just before
+;;; #x1c000000.
+;;; ** Ideally the dynamic space should be at #x94000000, 64 MB
+;;; after the end of the highest random malloc() address.
+;;; Unfortunately the dynamic space must be in the lower half
+;;; of the address space, where there are no large areas which
+;;; are unused both with and without -Z. So we break -Z by
+;;; starting at #x40000000. By only using 512 - 64 MB we can
+;;; run under the default 512 MB data size resource limit.
+
+;;; NetBSD configuration used to have this comment regarding the linkage
+;;; table: "In CMUCL: 0xB0000000->0xB1000000"
+
+#!+win32 (!gencgc-space-setup #x22000000 nil nil #x10000)
+#!+linux (!gencgc-space-setup #x01000000 #x09000000)
+#!+sunos (!gencgc-space-setup #x20000000 #x48000000)
+#!+freebsd (!gencgc-space-setup #x01000000 #x58000000)
+#!+openbsd (!gencgc-space-setup #x1b000000 #x40000000)
+#!+netbsd (!gencgc-space-setup #x20000000 #x60000000)
+#!+darwin (!gencgc-space-setup #x04000000 #x10000000)
+
+;;; Size of one linkage-table entry in bytes.
+(def!constant linkage-table-entry-size 8)