[GHC] #12031: GHCi segfaults on Windows when compiling C code using extern-declared variable

[GHC]

#12031: GHCi segfaults on Windows when compiling C code using extern-declared
variable
--------------------------------+----------------------------------------
        Reporter:  RyanGlScott  |                Owner:  Phyx-
            Type:  bug          |               Status:  new
        Priority:  normal       |            Milestone:
       Component:  GHCi         |              Version:  8.0.1
      Resolution:               |             Keywords:
Operating System:  Windows      |         Architecture:  Unknown/Multiple
 Type of failure:  GHCi crash   |            Test Case:
      Blocked By:               |             Blocking:
 Related Tickets:               |  Differential Rev(s):
       Wiki Page:               |
--------------------------------+----------------------------------------

Comment (by Phyx-):

 To round up the issue, the reason this seems to go wrong is because of how
 we initialize the `.bss` section for Windows in the runtime linker.

 The first issue is where we calculate the zero space for the section:

 {{{
 zspace = stgCallocBytes(1, bss_sz, "ocGetNames_PEi386(anonymous bss)");
 sectab_i->PointerToRawData = ((UChar*)zspace) - ((UChar*)(oc->image));
 }}}

 Where
 {{{
 UInt32 PointerToRawData;
 }}}

 This means we're stuffing a `64-bit` value into a `32-bit` one. Also
 `zspace` can be larger than `oc->image`. In which case it'll overflow and
 then get truncated in the cast.

 The address of a value in the `.bss` section is then calculated as:

 {{{
 addr = ((UChar*)(oc->image))
      + (sectabent->PointerToRawData
      + symtab_i->Value);
 }}}

 If it does truncate then this calculation won't be correct (which is what
 is happening).

 We then later use the value of `addr` as the `S` (Symbol) value for the
 relocations

 {{{
 S = (size_t) lookupSymbol_( (char*)symbol );
 }}}

 Now the majority of the relocations are `R_X86_64_PC32` etc. e.g. They are
 guaranteed to fit in a `32-bit` value.

 The `R_X86_64_64` introduced for these pseudo-relocations so they can use
 the full `48-bit` addressing space isn't as lucky. As for why it sometimes
 work has to do on whether the value is truncated or not.

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