I've been working on porting a lisp compiler (sbcl) to NetBSD/i386. It
likes to map large amounts of memory for its stack and dynamic data
area, and I would like to do this in a manner that does not stomp on
address ranges used by the C runtime environment or ld.so. So far I
have found the following areas used:

- mmap() with no specified address returns addresses starting from
around 0x48000000.
- therefore shared libraries get loaded starting from around 0x48000000.
- executables get (by default anyway) loaded around 0x8000000, so break
will also allocate memory from here on up.
- the C runtime stack grows down from the kernel boundary.

I wasn't able to find a definitive reference for these values. Is
there one, and if not, am I missing anything? Avoiding the ones listed
above got me what appears to be a working runtime environment.

Another question, as code may be modified on the fly in lisp and it
can move around due to GC, is it necessary or useful to call
msync(MS_INVALIDATE) on changed executable pages to flush caches (on
i386, given NetBSD 1.5 or 1.6)?

To enable the generational GC, I wrote a small patch to pass the
address that caused a SEGV as the fourth argument to signal
handlers. However, real SA_SIGINFO signals would be nice (sbcl expects
to see them otherwise too, but some wrapper functions took care of
that). I recall hearing that someone is working on these, is there any
word whether they are about to appear in -current anytime soon?

Thanks for any information. If anyone is interested in testing the
port, drop me a line.

 -v