[GHC] #14291: Tests tend to fail in the ext-interp way when split sections is enabled

GHC ghc-devs at haskell.org
Wed Oct 4 22:54:54 UTC 2017


#14291: Tests tend to fail in the ext-interp way when split sections is enabled
-------------------------------------+-------------------------------------
        Reporter:  bgamari           |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:  8.4.1
       Component:  Compiler          |              Version:  8.2.1
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:  13716
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by bgamari):

 So I plugged away at this a bit today. I'm increasingly suspicious of
 1c83fd814b12754be8af211a387cec906ca198b3 which touches a large amount of
 ELF linker logic. Unfortunately it's not terribly easy to revert.

 In particular, I've traced one failure down to what appears to be a
 section-name relocation. Namely,
 {{{#!objdump
 00000000001ee308 <s1MQ_info>:
   1ee308:       48 8d 45 f0             lea    -0x10(%rbp),%rax
   1ee30c:       4c 39 f8                cmp    %r15,%rax
   1ee30f:       72 23                   jb     1ee334 <s1MQ_info+0x2c>
   1ee311:       48 c7 45 f0 00 00 00    movq   $0x0,-0x10(%rbp)
   1ee318:       00
                         1ee315: R_X86_64_32S    stg_upd_frame_info
   1ee319:       48 89 5d f8             mov    %rbx,-0x8(%rbp)
   1ee31d:       be 00 00 00 00          mov    $0x0,%esi
                         1ee31e: R_X86_64_32     .data+0xe6db
 }}}

 Specifically, the relocation at 0x1ee31e. In the linked result this ends
 up pointing into the middle of
 `base_DataziData_zdfDataAnyzuzdcgunfold_closure`, which can't possibly be
 right.

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


More information about the ghc-tickets mailing list