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?
As far as I know GHC shouldn't touch x86-64's $rsp at all; we specifically avoid using it for the STG stack to ease FFI. It would be interesting to know what is touching it. Unfortunately, without a tool like rr this may be hard to find. Cheers, - Ben [1] http://rr-project.org/