"Elliott Slaughter" <elliottslaughter@...> writes:
>> I don't suppose compiling with :sb-thread automatically uses the EBX
>> modifications? Alastair's last transcript of attempting to compile
>> with EBX threading (http://paste.lisp.org/display/38635) suggests that
>> :x86-ebx-threads, :x86-reserve-ebx, and :x86-two-arg-passing-regs
>> should be present in *features*, but I didn't find them to be there
>> when compiling with only :sb-thread. Comments?
> Based on my previous hunch, I tried compiling with :x86-ebx-threads,
> :x86-reserve-ebx, and :x86-two-arg-passing-regs. Linux compiled and
> tested fine, although I am starting to have doubts about whether that
> means anything, since the system was really x86-64, not x86.
Right, it doesn't mean anything.
> (And I'm not sure how to do a cross-compile for just plain x86.)
If you're lucky, then "SBCL_ARCH=x86 ./make.sh" will do it. (Your
system might well need a bunch of clever development tools, but I
think it can be made to work; you might need to alter paths so that
gcc points to the 32-bit one, etc.)
Otherwise, install an x86 somewhere, virtualized or physical, or get
remote access to one.
> On win32, compilation failed (not unexpectedly). I resolved several C
> compilation errors, which got me past genesis, but upon attempting to
> load cold-sbcl.core into the new system, something broke and dropped
> the system into ldb (see below). In case more context is desirable, I
> have uploaded the entire session to
> http://blackthorncentral.net/files/sbcl_ebx-win32_build_log.7z .
> //doing warm init - compilation phase
> This is SBCL 126.96.36.199, an implementation of ANSI Common Lisp.
> More information about SBCL is available at <http://www.sbcl.org/>.
> SBCL is free software, provided as is, with absolutely no warranty.
> It is mostly in the public domain; some portions are provided under
> BSD-style licenses. See the CREDITS and COPYING files in the
> distribution for more information.
> This is experimental prerelease support for the Windows platform: use
> at your own risk. "Your Kitten of Death awaits!"
OK, so you're running Lisp code successfully, all the way up to warm
init of the system; on the other hand, you manage to corrupt the image
before or shortly afterwards, such that you don't get a nice friendly
debugger when something goes wrong. Allocation can't be completely
off, because there's a huge amount of allocation in cold-init. What
about GC? What happens if you disable the garbage collector (or
rather, don't re-enable it; look for (gc-on) and (gc :full t) in
One other thing to do is to review the entire patch, carefully, line
by line, until you're sure you understand how everything there
interacts. Another might be to make sure that the patch as applied to
the version of SBCL it was "designed" for works as it used to.