SBCL Internals The pages on this CLiki-driven site can be edited by anybody at any time. No warranty of any kind can therefore be made; any implied warranties of merchantability or fitness for a particular purpose are expressly disclaimed

* Segmentation faults that aren't due to stack exhaustion or gc triggering aren't handled properly. * One of the tests in smoke.impure.lisp fails frequently, but not always, and with a couple of different error messages.

The following summary is approximately 1.5 years out of date, but might prove useful for future reference.

I've spent time on and off working to port SBCL's runtime to NetBSD (x86). In general, I've had a small amount of success--I've been able to convince the runtime to compile and try to run initial mmaps. Since I'll be busy at work for at least the next 6 weeks, I thought I'd list my current stumbling blocks.

1) mmap behaves differently on NetBSD (vis a vis memory over-commit) than it does on FreeBSD and OpenBSD (???; they both use Chuck Silver's uvm).

2) more baffling is what to do about NetBSD's lack of support for some of the signal stuff found in interrupt.c (siginfo_t; sa_sigaction field in the sigaction struct; probably one more I don't remember).

SA_SIGINFO support has been added to -current netbsd. This means that one can head on over to releng.netbsd.org and pick up a kernel with the necessary changes at any time. Anyone interested in doing this work should contact Russell McManus (russell underscore mcmanus at yahoo dot com). Russell is willing to provide a temporary account on an i386 netbsd system running a kernel with these changes or this purpose. The change will not however be available in the upcoming NetBSD 1.6.1 release, but will be available in the next major release which will be numbered 2.0.

After seeing a post from Pierre Mai on c.l.l. about a CMUCL port to NetBSD, I asked him for advice. He sent me his files for NetBSD and indicated he worked around the mmap problem as well as the signal stuff (the signal stuff via a #define CMUCL already had; unfortunately, this means the NetBSD port of CMUCL can't use the generational garbage collector).

This page is linked from: index  

CLiki pages can be edited by anyone at any time. Imagine a fearsomely comprehensive disclaimer of liability. Now fear, comprehensively