"Nathan J. Williams" <nathanw@wasabisystems.com> writes:

> My question is this: why do you need to explicitly avoid those areas?
> mmap() won't give you a mapping that overlaps another mapping, so you
> should be able to let the system figure out where to place the various
> mappings of your process without conflict.

Two reasons:

1. The mappings need to be in fixed locations as the process of
dumping a lisp image saves these locations into the image. No
different from generating/loading (non-PIC) C code, I suppose. The
ranges are mapped when the runtime starts up and if it can't get them,
it has no option but to fail.

I'm not certain about whether this applies to the dynamic data area,
but even finding out would probably be a fair task.

2. I accidentally mapped a range starting at 0x48000000 yesterday. I
don't know what happened, but the next call to mmap() (which was
living at 0x48something) went off into the aether. I can't remember
what gdb said exactly, but at least there was no mmap where it was
supposed to be. These are MAP_FIXED|MAP_ANON|MAP_PRIVATE mappings.

 -v