[GHC] #13815: Support Windows big-obj format

[GHC]

#13815: Support Windows big-obj format
-------------------------------------+-------------------------------------
        Reporter:  Phyx-             |                Owner:  Phyx-
            Type:  feature request   |               Status:  patch
        Priority:  normal            |            Milestone:  8.4.1
       Component:  Compiler          |              Version:  8.0.1
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):  Phab:D3523
       Wiki Page:                    |
-------------------------------------+-------------------------------------

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

 In [changeset:"81377e9e4bd52256946114d9c1dd966d5e3e7692/ghc"
 81377e9e/ghc]:
 {{{
 #!CommitTicketReference repository="ghc"
 revision="81377e9e4bd52256946114d9c1dd966d5e3e7692"
 Big-obj support for the Windows runtime linker

 Summary:
 The normal object file on Windows has a limit of `2^16`
 sections that can be in an object-file.

 The `big-obj` format raises this to `2^32` sections.

 The implementation is made difficult because we now need to support
 two header formats and two section formats that differ only by a single
 element size within each. The element that's different is in the middle
 of the structs and since the structs are used to map regions of memory
 directly, it means we need to know which struct it is when we do the
 mapping or pointer arithmetics.

 This is the final Object-Code format which Windows compilers can generate
 which we do not support yet in GHCI. All other major compilers on the
 platforms
 can produce it and all linkers consume it (bfd and lld).

 See http://tinyurl.com/bigobj

 This patch abstracts away retrieving the fields to functions which all
 take
 an struct which describes which object format is currently being parsed.
 These functions are always in-lined as they're small but would looks messy
 being copy-pasted everywhere.

 Test Plan:
 ./validate and new test `big-obj`

 ```
 Tamar at Rage MINGW64 /r
 $ gcc -c -Wa,-mbig-obj foo.c -o foo.o

 Tamar at Rage MINGW64 /r
 $ objdump -h foo.o

 foo.o:     file format pe-bigobj-x86-64

 Sections:
 Idx Name          Size      VMA               LMA               File off
 Algn
   0 .text         00000010  0000000000000000  0000000000000000  00000128
 2**4
                   CONTENTS, ALLOC, LOAD, READONLY, CODE
   1 .data         00000000  0000000000000000  0000000000000000  00000000
 2**4
                   ALLOC, LOAD, DATA
   2 .bss          00000000  0000000000000000  0000000000000000  00000000
 2**4
                   ALLOC
   3 .xdata        00000008  0000000000000000  0000000000000000  00000138
 2**2
                   CONTENTS, ALLOC, LOAD, READONLY, DATA
   4 .pdata        0000000c  0000000000000000  0000000000000000  00000140
 2**2
                   CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
   5 .rdata$zzz    00000030  0000000000000000  0000000000000000  0000014c
 2**4
                   CONTENTS, ALLOC, LOAD, READONLY, DATA

 Tamar at Rage MINGW64 /r
 $ echo main | ~/ghc/inplace/bin/ghc-stage2.exe --interactive bar.hs foo.o
 GHCi, version 8.3.20170430: http://www.haskell.org/ghc/  :? for help
 [1 of 1] Compiling Main             ( bar.hs, interpreted )
 Ok, modules loaded: Main.
 *Main> 17
 *Main> Leaving GHCi.
 ```

 Reviewers: austin, bgamari, erikd, simonmar

 Subscribers: awson, rwbarton, thomie, #ghc_windows_task_force

 GHC Trac Issues: #13815

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

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