[Haskell-iPhone] help for ghc android cross compiler
Stephen Blackheath [to GHC-iPhone]
likeliest.complexions.stephen at blacksapphire.com
Wed Jan 16 02:47:47 CET 2013
All,
Here's an update. The bug "Call operand #8 has unhandled type
i32UNREACHABLE executed at CallingConvLower.cpp:129!" below turns out to
be specific to ARMv5, the old architecture I'm using. I raised a ticket
(7591) for that.
Here's the complete list of tickets that are currently blocking basic
cross-compiling:
http://hackage.haskell.org/trac/ghc/ticket/7571
http://hackage.haskell.org/trac/ghc/ticket/7569
http://hackage.haskell.org/trac/ghc/ticket/7575
http://hackage.haskell.org/trac/ghc/ticket/7591 (only if you're using
old ARM)
7575 is blocking me now, and there's no fix for it yet.
Steve
On 16/01/13 10:47, Stephen Blackheath [to GHC-iPhone] wrote:
> Nathan,
>
> llvm-3.1 (Ubuntu 12.10 stock verison) was what gave the bad code I
> mentioned previously (see below).
>
> Note: llvm can be very easily built from source. The location of llc and
> friends is detected by GHC's configure.
>
> llvm-3.2 gives this code, which looks correct:
>
> 00000000 <stg_returnToStackTop>:
> 0: e594608c ldr r6, [r4, #140] ; 0x8c
> 4: e3a03000 mov r3, #0
> 8: e596600c ldr r6, [r6, #12]
> c: e596500c ldr r5, [r6, #12]
> 10: e584309c str r3, [r4, #156] ; 0x9c
> 14: e286b064 add fp, r6, #100 ; 0x64
> 18: e5942094 ldr r2, [r4, #148] ; 0x94
> 1c: e892000a ldm r2, {r1, r3}
> 20: e592201c ldr r2, [r2, #28]
> 24: e0812602 add r2, r1, r2, lsl #12
> 28: e2436004 sub r6, r3, #4
> 2c: e2422001 sub r2, r2, #1
> 30: e5842084 str r2, [r4, #132] ; 0x84
> 34: e5950000 ldr r0, [r5]
> 38: e1a0e00f mov lr, pc
> 3c: e1a0f000 mov pc, r0
> 40: e1a0f00e mov pc, lr
>
> llvm-3.0 gives near identical code (slight variation in instruction order):
>
> 00000000 <stg_returnToStackTop>:
> 0: e594608c ldr r6, [r4, #140] ; 0x8c
> 4: e3a03000 mov r3, #0
> 8: e596600c ldr r6, [r6, #12]
> c: e596500c ldr r5, [r6, #12]
> 10: e584309c str r3, [r4, #156] ; 0x9c
> 14: e286b064 add fp, r6, #100 ; 0x64
> 18: e5942094 ldr r2, [r4, #148] ; 0x94
> 1c: e892000a ldm r2, {r1, r3}
> 20: e592201c ldr r2, [r2, #28]
> 24: e0812602 add r2, r1, r2, lsl #12
> 28: e2422001 sub r2, r2, #1
> 2c: e2436004 sub r6, r3, #4
> 30: e5842084 str r2, [r4, #132] ; 0x84
> 34: e5950000 ldr r0, [r5]
> 38: e1a0e00f mov lr, pc
> 3c: e1a0f000 mov pc, r0
> 40: e1a0f00e mov pc, lr
>
> Unfortunately llvm-3.2 doesn't quite work. I get this error:
>
> "inplace/bin/ghc-stage1" -static -H32m -O -package-name
> ghc-prim-0.3.1.0 -hide-all-packages -i -ilibraries/ghc-prim/.
> -ilibraries/ghc-prim/dist-install/build
> -ilibraries/ghc-prim/dist-install/build/autogen
> -Ilibraries/ghc-prim/dist-install/build
> -Ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/.
> -optP-include
> -optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h
> -package rts-1.0 -package-name ghc-prim -XHaskell98 -XCPP -XMagicHash
> -XForeignFunctionInterface -XUnliftedFFITypes -XUnboxedTuples
> -XEmptyDataDecls -XNoImplicitPrelude -O2 -no-user-package-db -rtsopts
> -odir libraries/ghc-prim/dist-install/build -hidir
> libraries/ghc-prim/dist-install/build -stubdir
> libraries/ghc-prim/dist-install/build -hisuf hi -osuf o -hcsuf hc -c
> libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.hs -o
> libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o
> You are using a new version of LLVM that hasn't been tested yet!
> We will try though...
> Call operand #8 has unhandled type i32UNREACHABLE executed at
> CallingConvLower.cpp:129!
> 0 llc 0x08d19668
> 1 llc 0x08d19c04
> 2 libpthread.so.0 0x40055f38
> 3 ld-linux.so.2 0x400011b2
> 4 libc.so.6 0x401c91df gsignal + 79
> 5 libc.so.6 0x401cc825 abort + 373
> 6 llc 0x08d026cc
> 7 llc 0x087ee1bd
> llvm::CCState::AnalyzeCallOperands(llvm::SmallVectorImpl<llvm::ISD::OutputArg>
> const&, bool (*)(unsigned int, llvm::MVT, llvm::MVT,
> llvm::CCValAssign::LocInfo, llvm::ISD::ArgFlagsTy, llvm::CCState&)) + 381
> 8 llc 0x0841e40c
> llvm::ARMTargetLowering::LowerCall(llvm::TargetLowering::CallLoweringInfo&,
> llvm::SmallVectorImpl<llvm::SDValue>&) const + 492
> 9 llc 0x086a3d1f
> llvm::TargetLowering::LowerCallTo(llvm::TargetLowering::CallLoweringInfo&)
> const + 6399
> 10 llc 0x086b3d0d
> llvm::SelectionDAGBuilder::LowerCallTo(llvm::ImmutableCallSite,
> llvm::SDValue, bool, llvm::MachineBasicBlock*) + 5341
> 11 llc 0x086bf029
> llvm::SelectionDAGBuilder::visitCall(llvm::CallInst const&) + 473
> 12 llc 0x086a7b46 llvm::SelectionDAGBuilder::visit(unsigned
> int, llvm::User const&) + 390
> 13 llc 0x086cdcd8
> llvm::SelectionDAGBuilder::visit(llvm::Instruction const&) + 88
> 14 llc 0x086e8add
> llvm::SelectionDAGISel::SelectBasicBlock(llvm::ilist_iterator<llvm::Instruction
> const>, llvm::ilist_iterator<llvm::Instruction const>, bool&) + 61
> 15 llc 0x086e97a5
> llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) + 3093
> 16 llc 0x086eb1c1
> llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 961
> 17 llc 0x08892d72
> llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 194
> 18 llc 0x08ca2883
> llvm::FPPassManager::runOnFunction(llvm::Function&) + 643
> 19 llc 0x08ca28ec
> llvm::FPPassManager::runOnModule(llvm::Module&) + 76
> 20 llc 0x08ca257c
> llvm::MPPassManager::runOnModule(llvm::Module&) + 540
> 21 llc 0x08ca6222 llvm::PassManagerImpl::run(llvm::Module&)
> + 162
> 22 llc 0x08ca6316 llvm::PassManager::run(llvm::Module&) + 38
> 23 llc 0x0818be9b main + 3707
> 24 libc.so.6 0x401b44d3 __libc_start_main + 243
> 25 llc 0x08199469
> Stack dump:
> 0. Program arguments: /usr/local/bin/llc -O3 -relocation-model=static
> /tmp/ghc19850_0/ghc19850_0.bc -o /tmp/ghc19850_0/ghc19850_0.lm_s
> --enable-tbaa=true
> 1. Running pass 'Function Pass Manager' on module
> '/tmp/ghc19850_0/ghc19850_0.bc'.
> 2. Running pass 'ARM Instruction Selection' on function
> '@ghczmprim_GHCziPrimopWrappers_ztzhzh_slow'
> /tmp/ghc19850_0/ghc19850_0.lm_s: openBinaryFile: does not exist (No such
> file or directory)
> make[1]: ***
> [libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.o] Error 1
> make: *** [all] Error 2
>
> (llvm-3.0 gave a vaguely similar error).
>
> So, the best option looks like to use llvm-3.2 and fix anything that
> isn't working.
>
>
> Steve
>
> On 16/01/13 09:28, Stephen Blackheath [to GHC-iPhone] wrote:
>> Nathan,
>>
>> My GHC-iOS is based on HEAD from about November 2012.
>>
>> The register that's used for base is defined in includes/stg/MachRegs.h
>> and is meant to be r4. This has never changed since the ARM work was
>> done. This is likely to be new breakage.
>>
>> One possibility: There are certain versions of llvm that break with GHC
>> and ARM. llvm-3.0 is known to work. I believe this has been fixed since
>> (so new llvm-version should work), but I haven't confirmed it.
>>
>> Looking at the cmm source for stg_returnToStackTop, the use of r0 looks
>> wrong because the comment says it's not using C arguments. r0-r3 are not
>> callee-saves and r0 is normally a C call argument and return value.
>>
>> I just did a compile for Emdebian Linux (but haven't run any generated
>> code yet), and I'm getting almost the same as you:
>>
>> 00000000 <stg_returnToStackTop>:
>> 0: e92d4010 push {r4, lr}
>> 4: e24dd010 sub sp, sp, #16
>> 8: e590108c ldr r1, [r0, #140] ; 0x8c
>> c: e3a04000 mov r4, #0
>> 10: e591200c ldr r2, [r1, #12]
>> 14: e592100c ldr r1, [r2, #12]
>> 18: e580409c str r4, [r0, #156] ; 0x9c
>> 1c: e2822064 add r2, r2, #100 ; 0x64
>> 20: e5904094 ldr r4, [r0, #148] ; 0x94
>> 24: e594c004 ldr ip, [r4, #4]
>> 28: e594e000 ldr lr, [r4]
>> 2c: e594401c ldr r4, [r4, #28]
>> 30: e08e4604 add r4, lr, r4, lsl #12
>> 34: e2444001 sub r4, r4, #1
>> 38: e5804084 str r4, [r0, #132] ; 0x84
>> 3c: e5914000 ldr r4, [r1]
>> 40: e58d200c str r2, [sp, #12]
>> 44: e24c2004 sub r2, ip, #4
>> 48: e1a0e00f mov lr, pc
>> 4c: e1a0f004 mov pc, r4
>> 50: e28dd010 add sp, sp, #16
>> 54: e8bd4010 pop {r4, lr}
>> 58: e1a0f00e mov pc, lr
>>
>> On the iPhone I get this:
>>
>> _stg_returnToStackTop:
>> 00000000 e5946064 ldr r6, [r4, #100]
>> 00000004 e3a03000 mov r3, #0 @ 0x0
>> 00000008 e596600c ldr r6, [r6, #12]
>> 0000000c e596500c ldr r5, [r6, #12]
>> 00000010 e5843074 str r3, [r4, #116]
>> 00000014 e286b064 add fp, r6, #100 @ 0x64
>> 00000018 e594306c ldr r3, [r4, #108]
>> 0000001c e1c300d0 ldrd r0, [r3]
>> 00000020 e593301c ldr r3, [r3, #28]
>> 00000024 e0803603 add r3, r0, r3, lsl #12
>> 00000028 e2416004 sub r6, r1, #4 @ 0x4
>> 0000002c e2433001 sub r3, r3, #1 @ 0x1
>> 00000030 e584305c str r3, [r4, #92]
>> 00000034 e5953000 ldr r3, [r5]
>> 00000038 e12fff33 blx r3
>> 0000003c e12fff1e bx lr
>>
>> A comparison strongly supports your idea that it's using r0 when it
>> should be using r4.
>>
>> I am going to try some different versions of llvm.
>>
>>
>> Steve
>>
>> On 16/01/13 06:59, Nathan Hüsken wrote:
>>> Hey,
>>>
>>> I am currently trying to get a ghc cross compiler for android linux to
>>> work.
>>> I am basing this on the development version (HEAD). I succeeded building
>>> the compiler. Unfortunately, the executables produced by the compiler
>>> segfault on my android device.
>>>
>>> If I do an unregisterised build, it works!
>>>
>>> Since the iphone is also an arm platform, I was hoping someone here
>>> could help me a little bit.
>>>
>>> I investigate the problem a little bit (see this thread:
>>> http://www.haskell.org/pipermail/ghc-devs/2013-January/000013.html) and
>>> I am guessing (I am no expert) that it is an arm problem, not android.
>>>
>>> It seems like the wrong register is used for base (r0 instead of r4).
>>>
>>> * On which ghc version is the iphone fork based?
>>> * Are there any arm fixes in the iphone fork that could be related to
>>> this?
>>>
>>> Thank you!
>>> Nathan
>>>
>>>
>>> _______________________________________________
>>> iPhone mailing list
>>> iPhone at haskell.org
>>> http://www.haskell.org/mailman/listinfo/iphone
>>>
>
> _______________________________________________
> iPhone mailing list
> iPhone at haskell.org
> http://www.haskell.org/mailman/listinfo/iphone
More information about the iPhone
mailing list