[GHC] #8965: bootstrapping failure on Linux/ppc64el
GHC
ghc-devs at haskell.org
Mon Apr 7 11:25:54 UTC 2014
#8965: bootstrapping failure on Linux/ppc64el
-----------------------------+--------------------------------------------
Reporter: cjwatson | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 7.8.1-rc2
Keywords: | Operating System: Linux
Architecture: powerpc64 | Type of failure: GHC doesn't work at all
Difficulty: Unknown | Test Case:
Blocked By: | Blocking:
Related Tickets: |
-----------------------------+--------------------------------------------
A few distributions, including Ubuntu which I work on, have a new little-
endian Linux ppc64 port (known variously as ppc64el, ppc64le, powerpc64le,
etc.). As well as the obvious endianness difference, this varies from
traditional ppc64 in that it uses a new version of the ELF ABI.
https://bugs.openjdk.java.net/browse/JDK-8035647 has a useful set of links
explaining the changes.
I've been trying to bootstrap GHC on this architecture, but I've been
running into failures, which I explained here along with my procedure:
https://lists.ubuntu.com/archives/ubuntu-devel-
discuss/2014-April/014922.html
Things that I believe I have ruled out so far:
* It's not libffi. In the above procedure I was missing unpacking
libffi6:ppc64el in the sysroot and configuring using `--with-system-
libffi` (our libffi is newer), but that makes no difference; furthermore,
breakpoints set on all exposed `ffi_*` symbols and on `createAdjustor`
never fire.
* It's not signal handling. I replaced unlit with a shell script that
sleeps 5 and then execs the real unlit, and ghc-stage2 segfaulted before
it returned; strace shows that SIGSEGV is the first signal received.
* It's not buggy native code generation. Although getting an NCG up on
this platform might be tractable later, for now I added a `powerpc64le*)
$2="powerpc64le" ;;` case before `powerpc64*` to `GHC_CONVERT_CPU` and
added powerpc64le to the `ArchUnknown` list in
`FPTOOLS_SET_HASKELL_PLATFORM_VARS`. Everything should be going via GCC.
* I don't think I'm taking a fundamentally wrong bootstrapping approach;
I'm using the exact same procedure and in fact I started from the exact
same git tree that I just used to successfully bootstrap GHC on arm64.
Here's a gdb trace showing the location of the segfault:
{{{
*** Literate pre-processor:
../inplace/lib/unlit -h HelloWorld.lhs HelloWorld.lhs
/tmp/ghc6597_0/ghc6597_1.lpp
Breakpoint 1, 0x000000001507daac in runInteractiveProcess ()
(gdb) bt
#0 0x000000001507daac in runInteractiveProcess ()
#1 0x000000001507d968 in c8z6_entry ()
#2 0x00003fffb7804a20 in ?? ()
Cannot access memory at address 0xf
(gdb) finish
Run till exit from #0 0x000000001507daac in runInteractiveProcess ()
0x000000001507d968 in c8z6_entry ()
(gdb) stepi
0x000000001507d96c in c8z6_entry ()
(gdb)
0x000000001507d970 in c8z6_entry ()
(gdb)
0x000000001507d974 in c8z6_entry ()
(gdb)
0x000000001507d978 in c8z6_entry ()
(gdb)
0x000000001507d97c in c8z6_entry ()
(gdb)
0x000000001507d980 in c8z6_entry ()
(gdb)
0x000000001507d984 in c8z6_entry ()
(gdb)
0x000000001507d988 in c8z6_entry ()
(gdb)
0x000000001507d98c in c8z6_entry ()
(gdb)
0x000000001507d990 in c8z6_entry ()
(gdb)
0x000000001507d994 in c8z6_entry ()
(gdb)
0x000000001507d998 in c8z6_entry ()
(gdb)
0x000000001507d99c in c8z6_entry ()
(gdb)
0x000000001507d9a0 in c8z6_entry ()
(gdb)
0x000000001507d9a4 in c8z6_entry ()
(gdb)
0x000000001507d9a8 in c8z6_entry ()
(gdb)
0x000000001507d9ac in c8z6_entry ()
(gdb)
0x000000001507d9b0 in c8z6_entry ()
(gdb)
0x000000001507d9e8 in c8z6_entry ()
(gdb)
Cannot access memory at address 0xf
(gdb) disas /rm
Dump of assembler code for function c8z6_entry:
0x000000001507d8ec <+0>: 6f 16 40 3c lis r2,5743
0x000000001507d8f0 <+4>: 20 9c 42 38 addi r2,r2,-25568
0x000000001507d8f4 <+8>: a6 02 08 7c mflr r0
0x000000001507d8f8 <+12>: 10 00 01 f8 std r0,16(r1)
0x000000001507d8fc <+16>: c1 ff 21 f8 stdu r1,-64(r1)
0x000000001507d900 <+20>: 00 00 00 60 nop
0x000000001507d904 <+24>: 60 92 22 39 addi r9,r2,-28064
0x000000001507d908 <+28>: 68 03 49 e9 ld r10,872(r9)
0x000000001507d90c <+32>: 10 00 4a 39 addi r10,r10,16
0x000000001507d910 <+36>: 68 03 49 f9 std r10,872(r9)
0x000000001507d914 <+40>: 58 03 69 e9 ld r11,856(r9)
0x000000001507d918 <+44>: 08 00 0b e8 ld r0,8(r11)
0x000000001507d91c <+48>: 70 03 29 e9 ld r9,880(r9)
0x000000001507d920 <+52>: 40 48 aa 7f cmpld cr7,r10,r9
0x000000001507d924 <+56>: 90 00 9d 41 bgt cr7,0x1507d9b4
<c8z6_entry+200>
0x000000001507d928 <+60>: 40 00 6b e8 ld r3,64(r11)
0x000000001507d92c <+64>: 38 00 8b e8 ld r4,56(r11)
0x000000001507d930 <+68>: 48 00 ab e8 ld r5,72(r11)
0x000000001507d934 <+72>: 50 00 cb e8 ld r6,80(r11)
0x000000001507d938 <+76>: 58 00 eb e8 ld r7,88(r11)
0x000000001507d93c <+80>: 10 00 0b e9 ld r8,16(r11)
0x000000001507d940 <+84>: 30 00 2b e9 ld r9,48(r11)
0x000000001507d944 <+88>: 28 00 4b e9 ld r10,40(r11)
0x000000001507d948 <+92>: 20 00 8b e9 ld r12,32(r11)
0x000000001507d94c <+96>: 20 00 81 f9 std r12,32(r1)
0x000000001507d950 <+100>: 00 00 8b e9 ld r12,0(r11)
0x000000001507d954 <+104>: 28 00 81 f9 std r12,40(r1)
0x000000001507d958 <+108>: 30 00 01 f8 std r0,48(r1)
0x000000001507d95c <+112>: 18 00 6b e9 ld r11,24(r11)
0x000000001507d960 <+116>: 38 00 61 f9 std r11,56(r1)
0x000000001507d964 <+120>: 19 01 00 48 bl 0x1507da7c
<runInteractiveProcess+8>
0x000000001507d968 <+124>: 00 00 00 60 nop
0x000000001507d96c <+128>: 00 00 00 60 nop
0x000000001507d970 <+132>: 60 92 22 39 addi r9,r2,-28064
0x000000001507d974 <+136>: 68 03 49 e9 ld r10,872(r9)
0x000000001507d978 <+140>: f6 ff e2 3c addis r7,r2,-10
0x000000001507d97c <+144>: 30 17 07 39 addi r8,r7,5936
0x000000001507d980 <+148>: f8 ff 0a f9 std r8,-8(r10)
0x000000001507d984 <+152>: 68 03 49 e9 ld r10,872(r9)
0x000000001507d988 <+156>: b4 07 63 7c extsw r3,r3
0x000000001507d98c <+160>: 00 00 6a f8 std r3,0(r10)
0x000000001507d990 <+164>: 68 03 49 e9 ld r10,872(r9)
0x000000001507d994 <+168>: f9 ff 4a 39 addi r10,r10,-7
0x000000001507d998 <+172>: 18 00 49 f9 std r10,24(r9)
0x000000001507d99c <+176>: 58 03 49 e9 ld r10,856(r9)
0x000000001507d9a0 <+180>: 60 00 0a 39 addi r8,r10,96
0x000000001507d9a4 <+184>: 58 03 09 f9 std r8,856(r9)
0x000000001507d9a8 <+188>: 60 00 2a e9 ld r9,96(r10)
0x000000001507d9ac <+192>: 00 00 69 e8 ld r3,0(r9)
0x000000001507d9b0 <+196>: 38 00 00 48 b 0x1507d9e8
<c8z6_entry+252>
0x000000001507d9b4 <+200>: 00 00 00 60 nop
0x000000001507d9b8 <+204>: 60 92 22 39 addi r9,r2,-28064
0x000000001507d9bc <+208>: 10 00 40 39 li r10,16
0x000000001507d9c0 <+212>: a0 03 49 f9 std r10,928(r9)
0x000000001507d9c4 <+216>: da ff 42 3d addis r10,r2,-38
0x000000001507d9c8 <+220>: 38 36 4a 39 addi r10,r10,13880
0x000000001507d9cc <+224>: f8 ff 4b f9 std r10,-8(r11)
0x000000001507d9d0 <+228>: 18 00 09 f8 std r0,24(r9)
0x000000001507d9d4 <+232>: 58 03 49 e9 ld r10,856(r9)
0x000000001507d9d8 <+236>: f8 ff 4a 39 addi r10,r10,-8
0x000000001507d9dc <+240>: 58 03 49 f9 std r10,856(r9)
0x000000001507d9e0 <+244>: 3b ff e2 3c addis r7,r2,-197
0x000000001507d9e4 <+248>: 60 c0 67 38 addi r3,r7,-16288
0x000000001507d9e8 <+252>: 40 00 21 38 addi r1,r1,64
=> 0x000000001507d9ec <+256>: 10 00 01 e8 ld r0,16(r1)
---Type <return> to continue, or q <return> to quit---
0x000000001507d9f0 <+260>: a6 03 08 7c mtlr r0
0x000000001507d9f4 <+264>: 20 00 80 4e blr
0x000000001507d9f8 <+268>: 00 00 00 00 .long 0x0
0x000000001507d9fc <+272>: 00 00 00 01 .long 0x1000000
0x000000001507da00 <+276>: 80 00 00 00 .long 0x80
End of assembler dump.
(gdb)
}}}
Let me know what else I could try.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8965>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list