ghc, OpenBSD and stack pointer checking

[Ben Gamari]

Matthias Kilian <kili at outback.escape.de> 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.

Cheers,

- Ben

[1] http://rr-project.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20180118/64358825/attachment.sig>