[GHC] #8024: Illegal instruction in cr_str

#8024: Illegal instruction in cr_str --------------------------------+------------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Linux | Architecture: powerpc Failure: Building GHC failed | Blockedby: Blocking: | Related: --------------------------------+------------------------------------------- During the process of coming up for a fix for ticket #7830 (which left GHC un-buildable for many months) I ran into this problem. After coming up with a fix for #7830 I ran into this problem where the first executable (compiled with the stage1 compiler) to run crashes with an illegal instruction: {{{ (gdb) bt #0 0x0f3f2e24 in cr_str () from /home/erikd/Git/ghc- upstream/rts/dist/build/libHSrts-ghc7.7.20130630.so #1 0x0f3de490 in stg_catchzh () from /home/erikd/Git/ghc- upstream/rts/dist/build/libHSrts-ghc7.7.20130630.so #2 0x0f3cc01c in scheduleWaitThread () from /home/erikd/Git/ghc- upstream/rts/dist/build/libHSrts-ghc7.7.20130630.so #3 0x0f3c63dc in rts_evalLazyIO () from /home/erikd/Git/ghc- upstream/rts/dist/build/libHSrts-ghc7.7.20130630.so #4 0x0f3c8300 in hs_main () from /home/erikd/Git/ghc- upstream/rts/dist/build/libHSrts-ghc7.7.20130630.so #5 0x10006ae4 in main () }}} Disassmbling the function gives: {{{ Dump of assembler code for function cr_str: 0x0f3f2dec: rlwimi r1,r2,10,0,16 0x0f3f2df0: xoris r2,r27,27237 0x0f3f2df4: ori r20,r27,8293 0x0f3f2df8: xoris r20,r19,25970 0x0f3f2dfc: oris r4,r11,8448 0x0f3f2e00: .long 0xfffeae2c 0x0f3f2e04: .long 0xfffeae2c 0x0f3f2e08: .long 0xfffeae2c 0x0f3f2e0c: .long 0xfffeae2c 0x0f3f2e10: .long 0xfffeae2c 0x0f3f2e14: .long 0xfffeae2c 0x0f3f2e18: .long 0xfffeae2c 0x0f3f2e1c: .long 0xfffeae2c 0x0f3f2e20: .long 0xfffeae2c => 0x0f3f2e24: .long 0xfffeae20 0x0f3f2e28: .long 0xfffeae20 0x0f3f2e2c: .long 0xfffeae20 0x0f3f2e30: .long 0xfffeae20 }}} However function stg_catchzh() in rts/Exception.cmm does not call cr_str(). -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/8024 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#8024: Dynamic linking not working on PowerPC Linux. --------------------------------+------------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Linux | Architecture: powerpc Failure: Building GHC failed | Blockedby: Blocking: | Related: --------------------------------+------------------------------------------- Description changed by erikd: Old description:
During the process of coming up for a fix for ticket #7830 (which left GHC un-buildable for many months) I ran into this problem.
After coming up with a fix for #7830 I ran into this problem where the first executable (compiled with the stage1 compiler) to run crashes with an illegal instruction:
{{{ (gdb) bt #0 0x0f3f2e24 in cr_str () from /home/erikd/Git/ghc- upstream/rts/dist/build/libHSrts-ghc7.7.20130630.so #1 0x0f3de490 in stg_catchzh () from /home/erikd/Git/ghc- upstream/rts/dist/build/libHSrts-ghc7.7.20130630.so #2 0x0f3cc01c in scheduleWaitThread () from /home/erikd/Git/ghc- upstream/rts/dist/build/libHSrts-ghc7.7.20130630.so #3 0x0f3c63dc in rts_evalLazyIO () from /home/erikd/Git/ghc- upstream/rts/dist/build/libHSrts-ghc7.7.20130630.so #4 0x0f3c8300 in hs_main () from /home/erikd/Git/ghc- upstream/rts/dist/build/libHSrts-ghc7.7.20130630.so #5 0x10006ae4 in main () }}}
Disassmbling the function gives:
{{{ Dump of assembler code for function cr_str: 0x0f3f2dec: rlwimi r1,r2,10,0,16 0x0f3f2df0: xoris r2,r27,27237 0x0f3f2df4: ori r20,r27,8293 0x0f3f2df8: xoris r20,r19,25970 0x0f3f2dfc: oris r4,r11,8448 0x0f3f2e00: .long 0xfffeae2c 0x0f3f2e04: .long 0xfffeae2c 0x0f3f2e08: .long 0xfffeae2c 0x0f3f2e0c: .long 0xfffeae2c 0x0f3f2e10: .long 0xfffeae2c 0x0f3f2e14: .long 0xfffeae2c 0x0f3f2e18: .long 0xfffeae2c 0x0f3f2e1c: .long 0xfffeae2c 0x0f3f2e20: .long 0xfffeae2c => 0x0f3f2e24: .long 0xfffeae20 0x0f3f2e28: .long 0xfffeae20 0x0f3f2e2c: .long 0xfffeae20 0x0f3f2e30: .long 0xfffeae20 }}}
However function stg_catchzh() in rts/Exception.cmm does not call cr_str().
New description: With dynamic linking enabled, the first binary compiled by the stage1 compiler (dll-split) crashes with an illegal instruction exception. {{{ (gdb) bt #0 0x0f3f2e24 in cr_str () from /home/erikd/Git/ghc- upstream/rts/dist/build/libHSrts-ghc7.7.20130630.so #1 0x0f3de490 in stg_catchzh () from /home/erikd/Git/ghc- upstream/rts/dist/build/libHSrts-ghc7.7.20130630.so #2 0x0f3cc01c in scheduleWaitThread () from /home/erikd/Git/ghc- upstream/rts/dist/build/libHSrts-ghc7.7.20130630.so #3 0x0f3c63dc in rts_evalLazyIO () from /home/erikd/Git/ghc- upstream/rts/dist/build/libHSrts-ghc7.7.20130630.so #4 0x0f3c8300 in hs_main () from /home/erikd/Git/ghc- upstream/rts/dist/build/libHSrts-ghc7.7.20130630.so #5 0x10006ae4 in main () }}} Disassmbling the function gives: {{{ Dump of assembler code for function cr_str: 0x0f3f2dec: rlwimi r1,r2,10,0,16 0x0f3f2df0: xoris r2,r27,27237 0x0f3f2df4: ori r20,r27,8293 0x0f3f2df8: xoris r20,r19,25970 0x0f3f2dfc: oris r4,r11,8448 0x0f3f2e00: .long 0xfffeae2c 0x0f3f2e04: .long 0xfffeae2c 0x0f3f2e08: .long 0xfffeae2c 0x0f3f2e0c: .long 0xfffeae2c 0x0f3f2e10: .long 0xfffeae2c 0x0f3f2e14: .long 0xfffeae2c 0x0f3f2e18: .long 0xfffeae2c 0x0f3f2e1c: .long 0xfffeae2c 0x0f3f2e20: .long 0xfffeae2c => 0x0f3f2e24: .long 0xfffeae20 0x0f3f2e28: .long 0xfffeae20 0x0f3f2e2c: .long 0xfffeae20 0x0f3f2e30: .long 0xfffeae20 }}} However function stg_catchzh() in rts/Exception.cmm does not call cr_str(). If I disable dynamic lbraries by adding powerpc-unknow-linux to `NoSharedLibsPlatformList` in `mk/config.mk.in` then the compile builds. -- -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/8024#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
participants (1)
-
GHC