#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