[GHC] #10155: [PATCH] Possibly incorrect stack pointer usage in StgRun() on x86_64

[GHC]

#10155: [PATCH] Possibly incorrect stack pointer usage in StgRun() on x86_64
-------------------------------------+-------------------------------------
        Reporter:  stengel           |                   Owner:
                                     |  thoughtpolice
            Type:  bug               |                  Status:  patch
        Priority:  high              |               Milestone:  7.12.1
       Component:  Runtime System    |                 Version:  7.8.1
      Resolution:                    |                Keywords:
Operating System:  Unknown/Multiple  |            Architecture:  x86_64
                                     |  (amd64)
 Type of failure:  Other             |               Test Case:
      Blocked By:                    |                Blocking:
 Related Tickets:                    |  Differential Revisions:
-------------------------------------+-------------------------------------

Comment (by Ben Gamari <ben@…>):

 In [changeset:"b38ee89c8c8724ba2feb98d4082795a5d4ae96f6/ghc"
 b38ee89c/ghc]:
 {{{
 #!CommitTicketReference repository="ghc"
 revision="b38ee89c8c8724ba2feb98d4082795a5d4ae96f6"
 Fix incorrect stack pointer usage in StgRun() on x86_64

 The STG_RETURN code from StgCRun.c is incorrect for x86_64 variants
 where the ABI doesn't impose a mandatory red zone for the stack, like on
 Windows or Xen/HaLVM. The current implementation restores the stack
 pointer first, which effectively marks the area with the saved registers
 as reusable. Later, the CPU registers are restored from this "free"
 area.

 This ordering happens to work by accident on operating systems that
 strictly adhere to the System V ABI, because any interrupt/signal
 delivery is guaranteed to leave the first 128 bytes past the stack
 pointer untouched (red zone). On other systems this might result in
 corrupted CPU registers if an interruption happens just after restoring
 the stack pointer.

 The red zone is usually only used by small leaf functions to avoid
 updates to the stack pointer and exploiting it doesn't give us any
 advantage in this case.

 Reviewers: austin, rwbarton

 Reviewed By: rwbarton

 Subscribers: thomie, simonmar

 Differential Revision: https://phabricator.haskell.org/D1120

 GHC Trac Issues: #10155
 }}}

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10155#comment:4>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler