[GHC] #13617: GHCI Linker incorrectly handles the R_X86_64_PC32 relocation (was: Segfault in Windows GHCi involving C code compiled with -O4)

[GHC]

#13617: GHCI Linker incorrectly handles the R_X86_64_PC32 relocation
--------------------------------+----------------------------------------
        Reporter:  RyanGlScott  |                Owner:  Phyx-
            Type:  bug          |               Status:  new
        Priority:  normal       |            Milestone:
       Component:  GHCi         |              Version:  8.0.2
      Resolution:               |             Keywords:
Operating System:  Windows      |         Architecture:  Unknown/Multiple
 Type of failure:  GHCi crash   |            Test Case:
      Blocked By:               |             Blocking:
 Related Tickets:  #7134        |  Differential Rev(s):
       Wiki Page:               |
--------------------------------+----------------------------------------
Changes (by Phyx-):

 * owner:  (none) => Phyx-
 * related:   => #7134


Comment:

 So I've finally had some time to track this one down.

 The difference between the `-O2` and the `-O3` code is that the `-O3` code
 is vectorized and the constants are moved to `.rdata`. To get to the
 constants a `R_X86_64_PC32` relocation is used.

 {{{
   ac:   48 c1 e0 02             shl    $0x2,%rax
   b0:   31 db                   xor    %ebx,%ebx
   b2:   66 0f 6f 15 00 00 00    movdqa 0x0(%rip),%xmm2        # ba
 <stepI+0xba>
   b9:   00
                         b6: R_X86_64_PC32       .rdata
   ba:   48 8d 2c 02             lea    (%rdx,%rax,1),%rbp
   be:   41 c1 ea 02             shr    $0x2,%r10d
 }}}

 At runtime the program segfaults at `0xb2` when attempting to read from
 `.rdata`.

 {{{
    │0xced01d2       shl    $0x2,%rax
 │
    │0xced01d6       xor    %ebx,%ebx
 │
   >│0xced01d8       movdqa 0xd8(%rip),%xmm2        # 0xced02b8
 │
    │0xced01e0       lea    (%rdx,%rax,1),%rbp
 │
    │0xced01e4       shr    $0x2,%r10d
 }}}

 The calculated address for `.rdata` is correct, `0xced02b8`:

 {{{
 (gdb) x/10i 0xced02b8
    0xced02b8:   add    %eax,(%rax)
    0xced02ba:   add    %al,(%rax)
    0xced02bc:   add    %eax,(%rax)
    0xced02be:   add    %al,(%rax)
    0xced02c0:   add    %eax,(%rax)
    0xced02c2:   add    %al,(%rax)
    0xced02c4:   add    %eax,(%rax)
    0xced02c6:   add    %al,(%rax)
    0xced02c8:   rex.RXB
    0xced02c9:   rex.XB
 }}}

 and the object file has

 {{{
 Disassembly of section .rdata:

 0000000000000000 <.rdata>:
    0:   01 00                   add    %eax,(%rax)
    2:   00 00                   add    %al,(%rax)
    4:   01 00                   add    %eax,(%rax)
    6:   00 00                   add    %al,(%rax)
    8:   01 00                   add    %eax,(%rax)
    a:   00 00                   add    %al,(%rax)
    c:   01 00                   add    %eax,(%rax)
         ...
 }}}


 However the code is referencing this address. So I suspect it's expecting
 a trampoline here. So perhaps `R_X86_64_PC32` should be allocated using a
 jump island.

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