Matthias Kilian
Hi,
Hi Matthias, ...
However, after building ghc-8.6 with all the WXNNEDED stuff removed, and running ghci from this build, I still get an abort because pages are mapped both writable and executable (I've configured my system to abort processes when a W^X violation happens). Here's a backtrace in case it's helpfull at all:
#0 _thread_sys___syscall () at -:3 #1 0x00000002010bb179 in _libc_mmap (addr=Variable "addr" is not available.) at /usr/src/lib/libc/sys/mmap.c:47 #2 0x000000021be22374 in mmapForLinker (bytes=Variable "bytes" is not available.) at rts/Linker.c:1029 #3 0x000000021be3e99b in m32_allocator_init () at rts/linker/M32Alloc.c:160 #4 0x00000002fd518be1 in cimc_info () from /usr/local/lib/ghc/bin/../ghci-8.6.4/libHSghci-8.6.4-ghc8.6.4.so #5 0x0000000000000000 in ?? ()
Any thougts about this?
I suspect what you ran into here is GHCi loading a static archive: I tried running GHCi compiled with debug information under GDB, set a breakpoint on m32_allocator_init and found the following: >>> bt #0 m32_allocator_init () at rts/linker/M32Alloc.c:155 #1 0x00007ffff2d680b7 in ghcizm8zi9zi0zi20191022_GHCiziRun_run1_info () from _build/stage1/lib/../lib/x86_64-linux-ghc-8.9.0.20191022/libHSghci-8.9.0.20191022-ghc8.9.0.20191022.so #2 0x0000000000000000 in ?? () While the backtrace doesn't reveal this, the caller appears to be initLinker_ which I suspect is called by GHCi.ObjLink.initObjLinker (which is in turn called by GHCi.Run.run). I have opened #17407 to track this.
And, since W|X (and nopie) isn't good on any system: is anyone working on getting rid of this for other unixes?
There has been some work on this on Darwin (see #13624). Unfortunately no work has been put into ridding other platforms of W|X mappings (e.g. see #12657). It would be great if you felt you could contribute some help! Cheers, - Ben