Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 123698 - all binaries built by ghc have executable stacks
Summary: all binaries built by ghc have executable stacks
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo's Haskell Language team
: 123711 (view as bug list)
Depends on:
Reported: 2006-02-22 03:39 UTC by Duncan Coutts (RETIRED)
Modified: 2006-03-15 03:55 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Duncan Coutts (RETIRED) gentoo-dev 2006-02-22 03:39:36 UTC
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.
Comment 1 solar (RETIRED) gentoo-dev 2006-02-22 07:17:34 UTC
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?
Comment 2 Duncan Coutts (RETIRED) gentoo-dev 2006-02-22 08:09:33 UTC
*** Bug 123711 has been marked as a duplicate of this bug. ***
Comment 3 Duncan Coutts (RETIRED) gentoo-dev 2006-02-22 08:38:31 UTC
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:

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.
Comment 4 solar (RETIRED) gentoo-dev 2006-02-22 08:50:22 UTC
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?
Comment 5 Duncan Coutts (RETIRED) gentoo-dev 2006-02-22 09:02:22 UTC
This has been reported upstream:
Comment 6 Duncan Coutts (RETIRED) gentoo-dev 2006-02-22 09:05:29 UTC
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.
Comment 7 Duncan Coutts (RETIRED) gentoo-dev 2006-02-22 09:46:34 UTC
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.
Comment 8 SpanKY gentoo-dev 2006-02-22 20:36:53 UTC
> 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 requires executable stack, it'll get it ... you're simply forcing executable stack policy on the final ELF ghc produces, that's it
Comment 9 solar (RETIRED) gentoo-dev 2006-02-22 21:08:18 UTC
Does ghc have a spec file? Anything like gcc's own?
Comment 10 Duncan Coutts (RETIRED) gentoo-dev 2006-03-01 04:31:39 UTC
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.
Comment 11 Duncan Coutts (RETIRED) gentoo-dev 2006-03-10 16:29:04 UTC
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.
Comment 12 Duncan Coutts (RETIRED) gentoo-dev 2006-03-15 03:55:24 UTC
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.