[commit: ghc] master: Use check stacking on Windows. (1e795a0)

[git at git.haskell.org]

Repository : ssh://git@git.haskell.org/ghc

On branch  : master
Link       : http://ghc.haskell.org/trac/ghc/changeset/1e795a008da8ab2ae88cca04aca01c50967b4397/ghc

>---------------------------------------------------------------

commit 1e795a008da8ab2ae88cca04aca01c50967b4397
Author: Tamar Christina <tamar at zhox.com>
Date:   Sat Sep 17 22:25:00 2016 +0100

    Use check stacking on Windows.
    
    Summary:
    #8870 added as a temporary work around a much higher initial reserve
    and committed stack space of 2mb. This is causing problems with other windows applications.
    
    The hack was supposed to be temporary untill we could emit `__chkstk` instructions.
    But GCC can emit stack checks automatically for us if `-fstack-check` is passed.
    
    This will then emit calls to `___chkstk_ms` before stack allocations.
    
    ```
      633de0:       48 83 e0 f0             and    $0xfffffffffffffff0,%rax
      633de4:       e8 07 0c 0d 00          callq  7049f0 <___chkstk_ms>
      633de9:       48 29 c4                sub    %rax,%rsp
    ```
    
    The hack is now no longer needed.
    
    Test Plan: ./validate
    
    Reviewers: austin, erikd, awson, bgamari
    
    Reviewed By: bgamari
    
    Subscribers: thomie, #ghc_windows_task_force
    
    Differential Revision: https://phabricator.haskell.org/D2535
    
    GHC Trac Issues: #12186


>---------------------------------------------------------------

1e795a008da8ab2ae88cca04aca01c50967b4397
 compiler/main/SysTools.hs | 21 ++++++++-------------
 1 file changed, 8 insertions(+), 13 deletions(-)

diff --git a/compiler/main/SysTools.hs b/compiler/main/SysTools.hs
index 6cdb07e..e40b1d6 100644
--- a/compiler/main/SysTools.hs
+++ b/compiler/main/SysTools.hs
@@ -644,7 +644,7 @@ figureLlvmVersion dflags = do
 
 {- Note [Windows stack usage]
 
-See: Trac #8870 (and #8834 for related info)
+See: Trac #8870 (and #8834 for related info) and #12186
 
 On Windows, occasionally we need to grow the stack. In order to do
 this, we would normally just bump the stack pointer - but there's a
@@ -665,17 +665,11 @@ stack space in GHC itself. In the x86 codegen, we needed approximately
 ~12kb of stack space in one go, which caused the process to segfault,
 as the intervening pages were not committed.
 
-In the future, we should do the same thing, to make the problem
-completely go away. In the mean time, we're using a workaround: we
-instruct the linker to specify the generated PE as having an initial
-reserved stack size of 8mb, as well as a initial *committed* stack
-size of 8mb. The default committed size was previously only 4k.
+GCC can emit such a check for us automatically but only when the flag
+-fstack-check is used.
 
-Theoretically it's possible to still hit this problem if you request a
-stack bump of more than 8mb in one go. But the amount of code
-necessary is quite large, and 8mb "should be more than enough for
-anyone" right now (he said, before millions of lines of code cried out
-in terror).
+See https://gcc.gnu.org/onlinedocs/gnat_ugn/Stack-Overflow-Checking.html
+for more information.
 
 -}
 
@@ -828,11 +822,12 @@ getLinkerInfo' dflags = do
                    [ -- Reduce ld memory usage
                      "-Wl,--hash-size=31"
                    , "-Wl,--reduce-memory-overheads"
-                     -- Increase default stack, see
+                     -- Emit gcc stack checks
                      -- Note [Windows stack usage]
+                   , "-fstack-check"
                      -- Force static linking of libGCC
                      -- Note [Windows static libGCC]
-                   , "-Xlinker", "--stack=0x800000,0x800000", "-static-libgcc" ]
+                   , "-static-libgcc" ]
                _ -> do
                  -- In practice, we use the compiler as the linker here. Pass
                  -- -Wl,--version to get linker version info.