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@haskell.org http://www.haskell.org/mailman/listinfo/iphone
_______________________________________________ iPhone mailing list iPhone@haskell.org http://www.haskell.org/mailman/listinfo/iphone
_______________________________________________ iPhone mailing list iPhone@haskell.org http://www.haskell.org/mailman/listinfo/iphone