[Haskell-iPhone] help for ghc android cross compiler
Stephen Blackheath [to GHC-iPhone]
likeliest.complexions.stephen at blacksapphire.com
Tue Jan 15 22:47:54 CET 2013
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
>>
More information about the iPhone
mailing list