[Haskell-iPhone] help for ghc android cross compiler
Nathan Hüsken
nathan.huesken at posteo.de
Wed Jan 16 08:54:24 CET 2013
Hey,
Thanks! It is very motivating that I seemed to be on the right track
with the registeres.
I would not have suspected llvm...
Very cool, now I can pull on the right string.
Thanks!
Nathan
On 01/16/2013 02:47 AM, Stephen Blackheath [to GHC-iPhone] wrote:
> 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
>
> _______________________________________________
> iPhone mailing list
> iPhone at haskell.org
> http://www.haskell.org/mailman/listinfo/iphone
More information about the iPhone
mailing list