ghc, OpenBSD and stack pointer checking

[Matthias Kilian]

Hi,

while working on an ghc update for OpenBSD (to ghc-8.2.2), I tested
a diff for OpenBSD which enforces a special mmap(2) option, MAP_STACK
for the system stack and, if the check fails, just aborts the
process.[1] (Please note that this differs from the meaning of
MAP_STACK on some other operating systems)

At first, everything looked fine, but later during the build,
*sometimes* ghc (to be specific, inplace/lib/bin/ghc-stage2) got
aborted after *many* succesfull runs of it (for example, while
compiling the bundled haddock and after already a couple of haddock
sources had been successfully compiled).

So, if the stack pointer checking diff to OpenBSD is correct, and
if I'm not running into a completely unrelated problem: does ghc
and/or the runtime library sometimes move the system stack pointer
to newly allocated/mapped memory? If so, where in the code?

Please note: the check happens on traps and system calls, so the
doesn't happen when the stack pointer is changed to newly
allocated/mapped memory, but after the next trap or system call.

Unfurtunately, I was stupid enough to drop my recent build logs and
back traces, but they weren't very enlightening, anyway ;-) I may
to get some more information tomorrow or on thursday.

I'd appreciate any help on this. After all it's probably just a matter
of changing one call to mmap(2), shielded by an #ifdef.

Ciao and thanks in advance for any help,
	Kili

[1]: https://marc.info/?l=openbsd-tech&m=151572838911297&w=2