Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

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.