[GHC] #7794: GHCi "Prelude.undefined" exceptions on ARM; ByteCodeItbls.mkJumpToAddr unimplemented

[GHC]

#7794: GHCi "Prelude.undefined" exceptions on ARM; ByteCodeItbls.mkJumpToAddr
unimplemented
-----------------------+----------------------------------------------------
Reporter:  cjwatson    |          Owner:      
    Type:  bug         |         Status:  new 
Priority:  normal      |      Component:  GHCi
 Version:  7.6.2       |       Keywords:      
      Os:  Linux       |   Architecture:  arm 
 Failure:  GHCi crash  |      Blockedby:      
Blocking:              |        Related:      
-----------------------+----------------------------------------------------
 A number of non-trivial operations fail in ghci on ARM (specifically armhf
 on both Debian experimental and Ubuntu raring).  I initially noticed this
 as conduit's doctests failing, but reduced this to:

   $ ghci
   GHCi, version 7.6.2: http://www.haskell.org/ghc/  :? for help
   Loading package ghc-prim ... linking ... done.
   Loading package integer-gmp ... linking ... done.
   Loading package base ... linking ... done.
   Prelude> data Type a = Nothing
   *** Exception: Prelude.undefined

 This is a singularly unhelpful exception, coming as it does without
 context, but I eventually tracked it down to ByteCodeItbls.mkJumpToAddr
 having no specific implementation for ARM and thus falling back to the
 default of "undefined".  I've tried adding this:

 +#elif arm_TARGET_ARCH
 +type ItblCode = Word32
 +mkJumpToAddr a
 +    = [ 0xe51ff004      -- ldr pc, [pc, #-4]    # pc reads as <current
 insn>+8
 +      , fromIntegral (ptrToInt a) ]

 This definitely changes the nature of the problem, so I think I'm on the
 right track, and I'm reasonably confident that that's the correct branch
 implementation; but when I actually try it in practice I get crashes
 (SIGSEGV/SIGILL/SIGBUS) with trashed stack traces, so I'm clearly not done
 yet.  Friends of mine suggest that I may need to __clear_cache or
 equivalent, which sounds plausible, so my current line of attack is
 figuring out how to glue that in; but if any actual GHC hackers can spot
 something obviously missing in the meantime then that would be great.

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