Skip to content

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
    • Help
    • Support
    • Submit feedback
  • Sign in / Register
GHC
GHC
  • Project
    • Project
    • Details
    • Activity
    • Releases
    • Cycle Analytics
    • Insights
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Charts
    • Locked Files
  • Issues 3,615
    • Issues 3,615
    • List
    • Boards
    • Labels
    • Milestones
  • Merge Requests 204
    • Merge Requests 204
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
    • Charts
  • Security & Compliance
    • Security & Compliance
    • Dependency List
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Charts
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • Glasgow Haskell Compiler
  • GHCGHC
  • Issues
  • #703

Closed
Open
Opened Feb 22, 2006 by duncan@trac-duncan
  • Report abuse
  • New issue
Report abuse New issue

all binaries built by ghc have executable stacks

Non-executable stacks

The GNU toolchain supports marking object files that do not need to use an executable stack. Currently all object files produced by GHC lack these notes and so the linker defaults to using an executable stack for the resulting binary.

This makes some people grumpy. In particular it makes the Gentoo QA people grumpy. :-)

The long story: http://www.gentoo.org/proj/en/hardened/gnu-stack.xml

The quick story: Every .S file produced by ghc should include:

.section .note.GNU-stack,"",@progbits

Currently this does not happen for either -fasm or -fvia-C.

For -fasm

ghc simply does not emit the .section .note.GNU-stack stuff into the assembly output.

For -fvia-C

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

  1. 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.


For reference see http://bugs.gentoo.org/show_bug.cgi?id=123698

Trac metadata
Trac field Value
Version 6.4.1
Type Bug
TypeOfFailure OtherFailure
Priority normal
Resolution Unresolved
Component Driver
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture Multiple

Related issues

  • Discussion
  • Designs
Assignee
Assign to
7.10.1
Milestone
7.10.1
Assign milestone
Time tracking
None
Due date
None
4
Labels
bug driver P::normal Trac import
Assign labels
  • View project labels
Reference: ghc/ghc#703