[GHC] #13617: GHCi linker does not honor alignment of sections.

[GHC]

#13617: GHCi linker does not honor alignment of sections.
--------------------------------+----------------------------------------
        Reporter:  RyanGlScott  |                Owner:  Phyx-
            Type:  bug          |               Status:  patch
        Priority:  normal       |            Milestone:  8.8.1
       Component:  GHCi         |              Version:  8.0.2
      Resolution:               |             Keywords:
Operating System:  Windows      |         Architecture:  Unknown/Multiple
 Type of failure:  GHCi crash   |            Test Case:  T13617
      Blocked By:               |             Blocking:
 Related Tickets:  #7134        |  Differential Rev(s):  Phab:D3915
       Wiki Page:               |
--------------------------------+----------------------------------------

Comment (by Tamar Christina <tamar@…>):

 In [changeset:"5840734379da5d494a368d0b8a6edf1b1216a7f4/ghc" 5840734/ghc]:
 {{{
 #!CommitTicketReference repository="ghc"
 revision="5840734379da5d494a368d0b8a6edf1b1216a7f4"
 Updated PE linker, section alignment and cleanup.

 Summary:
 This patch is to address a couple of short comings of the PE linker.

 The first thing it does is properly honor section alignments, so SSE code
 will work reliably.

 While doing this I've also changed how it reads and stores ObjectFile
 information. Previously the entire object file was read in and treated
 as one blob, including headers, symbol tables etc.

 Now the ObjectFile is read in but stored in chunks, tables go into a
 temporary
 info struct and code/data into a new private heap. This allows me to free
 all
 meta data once we're done relocating. Which means we can reclaim this
 memory.

 As I've mentioned above I've also moved from using VirtualAlloc to
 HeapAlloc.
 The reason is VirtualAlloc is meant to be used for more low level memory
 allocation, it's very fast because it can only allocate whole blocks,
 (64k) by default, and the memory must be paged (4k) aligned.

 So when you ask for e.g. 30k of memory, you're given a whole block where
 34k
 will be wasted memory. Nothing else can ever access that untill you free
 the 30k.

 One downside of HeapAlloc is that you're not in control of how the heap
 grows,
 and heap memory is always committed. So it's harder to tell how much we're
 actually using now.

 Another big upside of splitting off the ObjectCode tables to info structs
 is that I can adjust them, so that later addressings can just use array
 subscripts to index into them. This simplifies the code a lot and a lot of
 complicated casts and indexing can be removed. Leaving less and more
 simple
 code.

 This patch doesn't fix the memprotection but it doesn't regress it either.
 It does however make the next changes smaller and fixes the alignments.

 Test Plan: ./validate , new test T13617

 Reviewers: bgamari, erikd, simonmar, hvr, angerman

 Reviewed By: angerman

 Subscribers: nickkuk, carter, RyanGlScott, rwbarton, thomie

 GHC Trac Issues: #13617

 Differential Revision: https://phabricator.haskell.org/D3915
 }}}

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