This affects ghc and all other ebuilds that use ghc. We have not yet figured out why this is happening. I suspect it may be due to ghc's "split objs" feature. We should see if it still happens with that turned off.
Do all ghc compiled executables require an executable stack/heap? Or os this just a matter of being mismarked? Do ghc compiled execitables contain a PT_GNU_STACK section at all?
*** Bug 123711 has been marked as a duplicate of this bug. ***
re comment #1; No ghc does not actually need an executable stack. The problem is that not all the things linked into a ghc-built binary have the PT_GNU_STACK section. So far I havn't been able to find which ones are missing it. I rad through the instructions: http://www.gentoo.org/proj/en/hardened/gnu-stack.xml After a bit more experimentation I have discovered some more useful info: ghc has two ways of compiling .hs files to .o files. One goes via C and one goes directly to assembly. For the -fasm method: ghc simply does not emit the .section .note.GNU-stack stuff into the assembly output. For the -fvia-C method: ghc emits C which is then compiled by gcc. The resulting .raw_s file does contain the .section .note.GNU-stack. However ghc then runs the generated assembly through the "evil mangler" which doesn't grok the .section .note.GNU-stack and does not emit it to the final assembly file. So the solution is to get ghc to emit the .note.GNU-stack in it's native code geneerator and to modify the evil mangler to pass the .note.GNU-stack through to the output. We may still have a problem with the "split objs" feature (which ghc uses for its own libraries). Hopefully it'd just be a matter of adding .note.GNU-stack to each .s file that is spat out by ghc -split-objs.
Duncan, Pretty good summary of the problem. Are you in direct contact with anybody upstream who might be able to work on a solution? Is it something you yourself might be able to work on? Also does the final linking happen using gnu-ld ? If so can -Wl,-z,noexecstack be forced? Can -Wa,--noexecstack be used?
This has been reported upstream: http://hackage.haskell.org/trac/ghc/ticket/703
I might be able to experiment with some patches to ghc. It may take some time however. Yes ghc does use gnu ld. We could try forcing a noexecstack option. We'll look into it.
So adding -optl-Wl,-z,noexecstack to the ghc driver script makes it work. This is a bit on the dangerious side however. It means we'll use a non-executable stack even if we're linking with a C lib that does need an executable stack (right?). For a simple hello world .hs file it's enough to add -opta-Wa,--noexecstack but this doesn't seem to work when building a larger program like cpphs. Presumably that's because in that case we're linking in lots of ghc libs that were not compiled with -opta-Wa,--noexecstack. So perhaps if this were added to the flags ghc uses to compile itself and it's libs then it'd be sufficient to just add -opta-Wa,--noexecstack to the ghc driver script. I've not tried this yet.
> So adding -optl-Wl,-z,noexecstack to the ghc driver script makes it work. This > is a bit on the dangerious side however. it is on the dangerous side in terms of silently breaking stuff > It means we'll use a non-executable stack even if we're linking with a C lib > that does need an executable stack (right?). no ... every ELF gets their own stack markings, so if some libfoo.so requires executable stack, it'll get it ... you're simply forcing executable stack policy on the final ELF ghc produces, that's it
Does ghc have a spec file? Anything like gcc's own?
So it looks like adding -opta-Wa,--noexecstack to the ghc driver script (and the flags we build ghc itself with) fixes everything. I'll add this to the ghc-6.4.1-r2 ebuild shortly.
This has now been done. This seems to be working but I think it needs a little more testing before I'm confident to call this fixed.
With the latest fix in the ghc ebuild I think this is now working ok. Note that ghc-bin still sufferes from this problem since they were built using eariler versions of the ghc ebuild. At the moment we don't think it's worth rebuilding the ghc-bin .tbz2 files on all arches to fix this QA bug. So it'll get fixed for ghc-bin next time we have to rebuild the .tbz2 files which will probably be with the next release ghc-6.4.2. I'll leave this bug open until next time ghc-bin gets rebuilt.
