Hi,
It is not powered on at the moment, but I am running
NetBSD-1.5Y-something on an IPC. There was some discussion of
problems relating to cmucl (and probably sbcl) getting either lisp
running on netbsd due to lack of fault address availability on SIGSEGV
receipt, and something to do with setrlimit(2). The code for the
experimental cmucl-netbsdx86 mentions this, as do some of the cliki
pages regarding sbcl and netbsd.
There has been mention of adding this to netbsd recently on the
tech-kern list. I am bad with names, so I apologise if I get this
wrong, but one of the correspondents I believe was earlier working on
a cmucl port to netbsd-sparc.
The man pages for the Solaris emulation mention I believe a struct
siginfo as part of the emulation set-up.
My recollection is that under NetBSD-1.4 emulation, the sunos4
cmucl-17f,18a did not succeed.
The netbsd-1.6 man page for sigaction mentions the
struct siginfo which amongst other things in OpenBSD provides this
implementation. My recollection was that some developers were of the
opinion that the infrastructure for siginfo was not yet built into
NetBSD, though the threads variant apparently could help provide some
of that work.
I have not pushed this to try building a cmucl with it, but in the
CLISP srcs, there is a suggestion about getting this fault address
information as a couple of minor changes to the i386 kernel for
NetBSD-1.1. One could try a parallel hack on the sparc sources and
rebuild. It strikes me that there is a right way to do this, but this
may work for getting the address from a hardware register.
Given that OpenBSD has the struct siginfo, if BSD variant doesn't
matter as much, one could try getting cmucl up and running on
OpenBSD-sparc. I have yet to succeed in getting it to compile itself
on the FreeBSD-i386 partition, but I haven't tried recently and don't
know much about it. Cross-compilation is the next logical step, but I
am not there yet.
The NetBSD folk are somewhat picky about correctness (I was recently
reproved for -Dunix), as no doubt are the OpenBSD folk so the problem
that Mr. Rhodes mentioned is perhaps less an issue in this context.
Granted, this is a politically sensitive area. I do not mean to
assert that some other Un*x is not picky about correctness. If one
has the time, knowledge, and resources, the less arch-bound an os
implementation of lisp seems structurally better. As I slowly acquire
elements of the above three, I shall try to help.
Regards,
John Towler
