ghc, OpenBSD and stack pointer checking

Ben Gamari ben at
Thu Jan 18 18:21:27 UTC 2018

Matthias Kilian <kili at> writes:

> 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.


- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <>

More information about the ghc-devs mailing list