Matthias Kilian <[email protected]> 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/
signature.asc
Description: PGP signature
_______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
