[GHC] #10375: arm: ghci hits an illegal instruction

[GHC]

#10375: arm: ghci hits an illegal instruction
-------------------------------------+-------------------------------------
        Reporter:  erikd             |                   Owner:
            Type:  bug               |                  Status:  new
        Priority:  high              |               Milestone:  7.10.3
       Component:  Runtime System    |                 Version:  7.10.1
  (Linker)                           |
      Resolution:                    |                Keywords:
Operating System:  Unknown/Multiple  |            Architecture:  arm
 Type of failure:  GHCi crash        |               Test Case:
      Blocked By:                    |                Blocking:
 Related Tickets:                    |  Differential Revisions:
-------------------------------------+-------------------------------------

Comment (by erikd):

 Bingo!

 I was building the compiler comfigured with `--enable-unregisterised` so
 that GDB be actually be useful. Noticed that loading `inplace/bin/ghc-
 stage2 --interactve` into GDB and running it caused a SIGILL here:

 {{{
 (gdb) disassemble
 Dump of assembler code for function stg_ap_v_fast:
    0x03ff9db4 <+0>:     push    {r7, lr}
    0x03ff9db6 <+2>:     sub     sp, #32
    0x03ff9db8 <+4>:     add     r7, sp, #0
    0x03ff9dba <+6>:     ldr     r3, [pc, #508]  ; (0x3ff9fb8
 <stg_ap_v_fast+516>)
 => 0x03ff9dbc <+8>:     ldr     r3, [r3, #0]
    0x03ff9dbe <+10>:    and.w   r3, r3, #
 }}}

 I also found that if I reloaded the debug target and set a break point in
 `stg_ap_v_fast` I could step though the code of that function without a
 crash. The `SIGILL` crash was only happening after executing a function
 that was loaded by the GHCi run time linker.

 The other clue in the assembly code for the `stg_ap_v_fast` funtcion was
 that it shows Thumb instructions (all Thumb instructions are encoded in
 two bytes whereas all Arm instructions are encoded in 4 bytes), and
 elsewhere I learned that `SIGILL` can occur when executng Arm instructions
 in Thumb mode and vice versa. In a monolithic executable, jumps from Arm
 code to Thumb code are correctly handled by the linker so the compiler
 itself was correctly linked.

 However, object code loaded at run time by GHCi is loaded by GHCi's run
 time linker which may not be getting the Arm/Thumb interop correct.

 Then I figured out that all Haskell code compiled via the LLVM backend
 generates pure Arm code but the C code compiler with GCC was Thumb code.

 Fortunately GCC can be forced to generate pure Arm code with the `-marm`
 option.

 With the `-marm` GHCi works when compiled `Unregisterised`. In
 `Registerised` mode there are still some problems:

 {{{
 Prelude> data X = X | Y deriving Eq
 Prelude> X == Y
 False
 Prelude> X == X

 Program received signal SIGSEGV, Segmentation fault.
 [Switching to Thread 0xb59ff460 (LWP 20022)]
 0xb6ff0024 in ?? ()
 (gdb) disass 0xb6ff0024
 No function contains specified address.
 (gdb) disass 0xb6ff0020,+10
 Dump of assembler code from 0xb6ff0020 to 0xb6ff002a:
    0xb6ff0020:  ldrbvs  r6, [r4, #-3689]!       ; 0xe69
 => 0xb6ff0024:  strbtvc r6, [r3], #-370 ; 0x172
    0xb6ff0028:  bcc     0xb894d9d4
 End of assembler dump.
 (gdb) info regs
 Undefined info command: "regs".  Try "help info".
 (gdb) info registers
 r0             0xb6ff0018       3070165016
 r1             0x28     40
 r2             0x1      1
 r3             0x70000000       1879048192
 r4             0x234db90        37018512
 r5             0xb6cd451c       3066905884
 r6             0xb6c1a33c       3066143548
 r7             0xb6cddbec       3066944492
 r8             0xb3a550fc       3013955836
 r9             0x7fffffff       2147483647
 r10            0x1e6d24c        31904332
 r11            0xb6cd4254       3066905172
 r12            0x234d37c        37016444
 sp             0x1316abc0       0x1316abc0
 lr             0x70000000       1879048192
 pc             0xb6ff0024       0xb6ff0024
 cpsr           0x400f0010       1074724880
 }}}

 The value of `r3`, 0x70000000 seems to be a strange address to be loading
 data from.

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