[GHC] #7040: ghci segfault on OS X X86_64 with foreign global data

[GHC]

#7040: ghci segfault on OS X X86_64 with foreign global data
------------------------------+---------------------------------------------
 Reporter:  luite             |          Owner:                
     Type:  bug               |         Status:  new           
 Priority:  normal            |      Component:  Compiler      
  Version:  7.4.2             |       Keywords:                
       Os:  Unknown/Multiple  |   Architecture:  x86_64 (amd64)
  Failure:  GHCi crash        |       Testcase:                
Blockedby:                    |       Blocking:                
  Related:                    |  
------------------------------+---------------------------------------------

Comment(by nus):

 The segfault happens when OS X calloc allocates space from the region
 beyond limits imposed by the small C code model.

 {{{
 Program stopped at 0x10b0fd624.
 It stopped with signal EXC_BAD_ACCESS, Could not access memory.

 (gdb) bt
 #0  0x000000010b0fd624 in ?? ()
 #1  0x000000010871043c in ffi_call_unix64 ()

 (gdb) x/20i 0x10b0fd624
 0x10b0fd624:    mov    0x7303d16(%rip),%eax        # 0x112401340
 0x10b0fd62a:    xor    %cl,%cl
 0x10b0fd62c:    lea    0x1c7(%rip),%rdx        # 0x10b0fd7fa
 0x10b0fd633:    mov    %rdx,%rdi
 0x10b0fd636:    mov    %eax,%esi
 0x10b0fd638:    mov    %cl,%al
 0x10b0fd63a:    callq  0x10b0fda70
 0x10b0fd63f:    movl   $0x1,0x7303cf7(%rip)        # 0x112401340
 0x10b0fd649:    mov    0x7303cf1(%rip),%ecx        # 0x112401340
 0x10b0fd64f:    xor    %dl,%dl
 0x10b0fd651:    lea    0x1a2(%rip),%rdi        # 0x10b0fd7fa
 0x10b0fd658:    mov    %ecx,%esi
 0x10b0fd65a:    mov    %dl,%al
 0x10b0fd65c:    callq  0x10b0fda70
 0x10b0fd661:    pop    %rbp
 0x10b0fd662:    retq
 0x10b0fd663:    add    %dl,(%rax)
 0x10b0fd665:    add    %al,(%rax)
 0x10b0fd667:    add    %bh,%bh
 0x10b0fd669:    (bad)

 (gdb) x/4w  0x10b0fd624
 0x10b0fd624:    0x3d16058b      0xc9300730      0xc7158d48      0x48000001
 }}}

 The relevant allocation:
 {{{
 ALLOC 0x7fdd12401340-0x7fdd12401343 [size=4]: thread_7fff72dbe960
 |s258_info | loadObj | loadOc | ocGetNames_MachO | stgCallocBytes | calloc
 | malloc_zone_calloc
 }}}

 rts/Linker.c truncates the pointer calloc returned (the offset is declared
 uint32_t):
 {{{
         if((sections[i].flags & SECTION_TYPE) == S_ZEROFILL)
         {
             char * zeroFillArea = stgCallocBytes(1,sections[i].size,
                                       "ocGetNames_MachO(common symbols)");
             sections[i].offset = zeroFillArea - image;
         }
 }}}
 From /usr/include/mach-o/loader.h:
 {{{
 struct section { /* for 32-bit architectures */
         char            sectname[16];   /* name of this section */
         char            segname[16];    /* segment this section goes in */
         uint32_t        addr;           /* memory address of this section
 */
         uint32_t        size;           /* size in bytes of this section
 */
         uint32_t        offset;         /* file offset of this section */
         uint32_t        align;          /* section alignment (power of 2)
 */
         uint32_t        reloff;         /* file offset of relocation
 entries */
         uint32_t        nreloc;         /* number of relocation entries */
         uint32_t        flags;          /* flags (section type and
 attributes)*/
         uint32_t        reserved1;      /* reserved (for offset or index)
 */
         uint32_t        reserved2;      /* reserved (for count or sizeof)
 */
 };
 }}}

 Even if it weren't truncated, the RIP-relative displacement is still
 required to fit into 32 bits.
 The analysis given in a comment in rts/Linker.c (see the bit starting "on
 x86_64 we have a problem with relocating symbol references") is also
 relevant to this situation.

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