any successfull ghc registerised builds on arm?

newer
Re: Error building ghc on...

older
GHCJS, JavaScript, cross-platform...

Nathan Hüsken

14 Jan 2013 14 Jan '13

12:15 p.m.

In a different thread (Error building ghc on raspberry pi): On 01/08/2013 12:27 PM, Thijs Alkemade wrote:(...)

...

I did eventually finish building stage2, but the final executable

segfaulted on start.

...

I haven't investigated much why that happened, the days it takes to rebuild it just made me give up.

Was that an registerised or unregisterised build? Did anyone succesfully build ghc on an arm system which produces non crashing executables? I am asking, because I build a arm-linux-androideabi cross compiler, but the executables crash. Only in an unregisterised build, they work. So I wonder if it is a general arm problem or has to do with android. Thanks! Nathan

Show replies by date

Stefan Kersten

14 Jan 14 Jan

12:57 p.m.

hi nathan, On Jan 14, 2013, at 6:15 PM, Nathan Hüsken wrote:

...

Did anyone succesfully build ghc on an arm system which produces non crashing executables?

I am asking, because I build a arm-linux-androideabi cross compiler, but the executables crash. Only in an unregisterised build, they work.

So I wonder if it is a general arm problem or has to do with android.

stephen blackheath's ghc port to iOS cross compiles to armv7 [1] (using llvm, registerised, i assume?). see [2] for a list of libraries i've built and run on iOS. here [3] is some info on cross compiling for blackberry arm (QNX). maybe it would be worthwhile asking on the iphone mailing list [4], too? sk [1] https://github.com/ghc-ios/ghc/wiki [2] https://github.com/kaoskorobase/ghc-ios-cabal-scripts [3] http://www.haskell.org/pipermail/iphone/2012-November/000142.html [4] http://www.haskell.org/mailman/listinfo/iphone

Karel Gardas

1:02 p.m.

On 01/14/13 06:15 PM, Nathan Hüsken wrote:

...

In a different thread (Error building ghc on raspberry pi):

On 01/08/2013 12:27 PM, Thijs Alkemade wrote:(...)

...
I did eventually finish building stage2, but the final executable

segfaulted on start.

...
I haven't investigated much why that happened, the days it takes to rebuild it just made me give up.

Was that an registerised or unregisterised build? Did anyone succesfully build ghc on an arm system which produces non crashing executables?

I am asking, because I build a arm-linux-androideabi cross compiler, but the executables crash. Only in an unregisterised build, they work.

So I wonder if it is a general arm problem or has to do with android.

I'm going to resurrect my pandaboard and build GHC HEAD hopefully this or next night. Also I plan resurrect ARM builder on i.MX53 QSB sometimes at the end of this month. Cheers, Karel

Stephen Paul Weber

19 Jan 19 Jan

1:04 a.m.

Somebody claiming to be Nathan Hüsken wrote:

...

Was that an registerised or unregisterised build? Did anyone succesfully build ghc on an arm system which produces non crashing executables?

Just finally got a BB10 device set up so I can test my cross-compiler on the ARM and I get: Process 26726597 (Main) terminated SIGSEGV code=2 fltno=11 ip=08bbf4c0(/accounts/1000/appdata/net.singpolyma.haskades_headlines.testDev_s_headlinesc1f463d0/app/native/Main@MD5Update+0xcc8d7) ref=e59d0040 Memory fault (core dumped) This seems related. I'm about to try a configuration with --enable-unregisterised to see if that helps. -- Stephen Paul Weber, @singpolyma See http://singpolyma.net for how I prefer to be contacted edition right joseph

Stephen Paul Weber

1:32 a.m.

Somebody claiming to be Stephen Paul Weber wrote:

...

Somebody claiming to be Nathan Hüsken wrote:

...
Was that an registerised or unregisterised build? Did anyone succesfully build ghc on an arm system which produces non crashing executables?

Just finally got a BB10 device set up so I can test my cross-compiler on the ARM

I'm about to try a configuration with --enable-unregisterised to see if that helps.

make -r --no-print-directory -f ghc.mk phase=final all "inplace/bin/ghc-stage1" -static -H64m -O0 -fasm -package-name integer-simple-0.1.1.0 -hide-all-packages -i -ilibraries/integer-simple/. -ilibraries/integer-simple/dist-install/build -ilibraries/integer-simple/dist-install/build/autogen -Ilibraries/integer-simple/dist-install/build -Ilibraries/integer-simple/dist-install/build/autogen -Ilibraries/integer-simple/. -optP-include -optPlibraries/integer-simple/dist-install/build/autogen/cabal_macros.h -package ghc-prim-0.3.1.0 -package-name integer-simple -Wall -XHaskell98 -XCPP -XMagicHash -XBangPatterns -XUnboxedTuples -XForeignFunctionInterface -XUnliftedFFITypes -XNoImplicitPrelude -O -fasm -no-user-package-db -rtsopts -odir libraries/integer-simple/dist-install/build -hidir libraries/integer-simple/dist-install/build -stubdir libraries/integer-simple/dist-install/build -hisuf hi -osuf o -hcsuf hc -c libraries/integer-simple/./GHC/Integer/Type.hs -o libraries/integer-simple/dist-install/build/GHC/Integer/Type.o when making flags consistent: Warning: Compiler unregisterised, so compiling via C /tmp/ghc25891_0/ghc25891_0.hc: In function 'c2pA_entry': /tmp/ghc25891_0/ghc25891_0.hc:3691:1: warning: this decimal constant is unsigned only in ISO C90 [enabled by default] /tmp/ghc25891_0/ghc25891_0.hc:3691:17: error: expected ')' before numeric constant make[1]: *** [libraries/integer-simple/dist-install/build/GHC/Integer/Type.o] Error 1 make: *** [all] Error 2 I think I can configure it to use unregistered LLVM, so I'm off to try that, but this seems like a bug. -- Stephen Paul Weber, @singpolyma See http://singpolyma.net for how I prefer to be contacted edition right joseph

Stephen Paul Weber

1:45 a.m.

Somebody claiming to be Stephen Paul Weber wrote:

...

Somebody claiming to be Stephen Paul Weber wrote:

...
Somebody claiming to be Nathan Hüsken wrote:

...
Was that an registerised or unregisterised build? Did anyone succesfully build ghc on an arm system which produces non crashing executables?

Just finally got a BB10 device set up so I can test my cross-compiler on the ARM

I'm about to try a configuration with --enable-unregisterised to see if that helps.

I think I can configure it to use unregistered LLVM, so I'm off to try that, but this seems like a bug.

Trying that gives me: [ 1 of 68] Compiling Distribution.Compat.Exception ( libraries/Cabal/Cabal/Distribution/Compat/Exception.hs, bootstrapping/Distribution/Compat/Exception.o ) Warning: Couldn't figure out LLVM version! Make sure you have installed LLVM ghc: could not execute: opt-3.0 make[1]: *** [utils/ghc-cabal/dist/build/tmp/ghc-cabal] Error 1 make: *** [all] Error 2 I'm using LLVM 3.1. This errors makes no sense to me, because when I just use "quick" and not unregistered, it falls back to LLVM and works fine, but now I've selected "quick-llvm" and unregistered and it can't find it? -- Stephen Paul Weber, @singpolyma See http://singpolyma.net for how I prefer to be contacted edition right joseph

Nathan Hüsken

5:28 a.m.

I got this error too. In my case it helped to install llvm-3.0 next to llvm (in ubuntu the executables are than called llc-3.0 and opt-3.0). I believe this error just came in the first phase, and was caused by the preinstalled ghc-7.4.2. But I am not sure. On 01/19/2013 07:45 AM, Stephen Paul Weber wrote:

...

Somebody claiming to be Stephen Paul Weber wrote:

...
Somebody claiming to be Stephen Paul Weber wrote:

...
Somebody claiming to be Nathan Hüsken wrote:

...
Was that an registerised or unregisterised build? Did anyone succesfully build ghc on an arm system which produces non crashing executables?

Just finally got a BB10 device set up so I can test my cross-compiler on the ARM

I'm about to try a configuration with --enable-unregisterised to see if that helps.

I think I can configure it to use unregistered LLVM, so I'm off to try that, but this seems like a bug.

Trying that gives me:

[ 1 of 68] Compiling Distribution.Compat.Exception ( libraries/Cabal/Cabal/Distribution/Compat/Exception.hs, bootstrapping/Distribution/Compat/Exception.o ) Warning: Couldn't figure out LLVM version! Make sure you have installed LLVM ghc: could not execute: opt-3.0 make[1]: *** [utils/ghc-cabal/dist/build/tmp/ghc-cabal] Error 1 make: *** [all] Error 2

I'm using LLVM 3.1. This errors makes no sense to me, because when I just use "quick" and not unregistered, it falls back to LLVM and works fine, but now I've selected "quick-llvm" and unregistered and it can't find it?

Ben Gamari

11:46 a.m.

Stephen Paul Weber writes:

...

Trying that gives me:

[ 1 of 68] Compiling Distribution.Compat.Exception ( libraries/Cabal/Cabal/Distribution/Compat/Exception.hs, bootstrapping/Distribution/Compat/Exception.o ) Warning: Couldn't figure out LLVM version! Make sure you have installed LLVM ghc: could not execute: opt-3.0 make[1]: *** [utils/ghc-cabal/dist/build/tmp/ghc-cabal] Error 1 make: *** [all] Error 2

I'm using LLVM 3.1. This errors makes no sense to me, because when I just use "quick" and not unregistered, it falls back to LLVM and works fine, but now I've selected "quick-llvm" and unregistered and it can't find it?

Are you certain the opt-3.0 is in $PATH? Perhaps verify this by `which opt-3.0`. Cheers, - Ben

Stephen Paul Weber

1:01 p.m.

Somebody claiming to be Ben Gamari wrote:

...

Stephen Paul Weber writes:

...
Trying that gives me:

Warning: Couldn't figure out LLVM version! Make sure you have installed LLVM ghc: could not execute: opt-3.0

I'm using LLVM 3.1.

Are you certain the opt-3.0 is in $PATH?

It isn't installed. I'm using LLVM 3.1, and GHC correctly uses opt-3.1 when I try the registered build. -- Stephen Paul Weber, @singpolyma See http://singpolyma.net for how I prefer to be contacted edition right joseph

Karel Gardas

5:37 p.m.

Hi, I just build 7.6.1 release on my ubuntu 12.04.1 LTS which is hard-float ABI distro. I used distro provided LLVM 3.0 and configured GHC with: ./configure --with-llc=/usr/bin/llc-3.0 --with-opt=/usr/bin/opt-3.0 And resulting ghc-stage2 is not only able to complete the build but also builds HelloWorld example which runs fine: $ ./inplace/bin/ghc-stage2 --info [("Project name","The Glorious Glasgow Haskell Compilation System") ,("GCC extra via C opts"," -fwrapv") ,("C compiler command","/usr/bin/gcc") ,("C compiler flags"," -fno-stack-protector -Wl,--hash-size=31 -Wl,--reduce-memory-overheads") ,("ar command","/usr/bin/ar") ,("ar flags","q") ,("ar supports at file","YES") ,("touch command","touch") ,("dllwrap command","/bin/false") ,("windres command","/bin/false") ,("perl command","/usr/bin/perl") ,("target os","OSLinux") ,("target arch","ArchARM {armISA = ARMv7, armISAExt = [VFPv3,NEON], armABI = HARD}") ,("target word size","4") ,("target has GNU nonexec stack","False") ,("target has .ident directive","True") ,("target has subsections via symbols","False") ,("LLVM llc command","/usr/bin/llc-3.0") ,("LLVM opt command","/usr/bin/opt-3.0") ,("Project version","7.6.1") ,("Booter version","7.4.1") ,("Stage","2") ,("Build platform","arm-unknown-linux") ,("Host platform","arm-unknown-linux") ,("Target platform","arm-unknown-linux") ,("Have interpreter","YES") ,("Object splitting supported","NO") ,("Have native code generator","NO") ,("Support SMP","YES") ,("Unregisterised","NO") ,("Tables next to code","YES") ,("RTS ways","l debug thr thr_debug thr_l thr_p ") ,("Leading underscore","NO") ,("Debug on","False") ,("LibDir","/export/home/karel/src/ghc-7.6.1/inplace/lib") ,("Global Package DB","/export/home/karel/src/ghc-7.6.1/inplace/lib/package.conf.d") ,("Gcc Linker flags","[\"-Wl,--hash-size=31\",\"-Wl,--reduce-memory-overheads\"]") ,("Ld Linker flags","[\"--hash-size=31\",\"--reduce-memory-overheads\"]") ] karel@panda:/export/home/karel/src/ghc-7.6.1$ karel@panda:/export/home/karel/src/ghc-7.6.1$ ./inplace/bin/ghc-stage2 --make HelloWorld.hs [1 of 1] Compiling Main ( HelloWorld.hs, HelloWorld.o ) Linking HelloWorld ... karel@panda:/export/home/karel/src/ghc-7.6.1$ ./HelloWorld Hello World! karel@panda:/export/home/karel/src/ghc-7.6.1$ Please keep in mind that GHC HEAD is completely different beast as there is new codegen put on by defaul there and LLVM codegen is not working correctly with it yet. Anyway, Austin Seipp seems to be working on fixing that. Thanks, Karel

Karel Gardas

20 Jan 20 Jan

12:13 p.m.

On 01/19/13 11:37 PM, Karel Gardas wrote:

...

Hi,

I just build 7.6.1 release on my ubuntu 12.04.1 LTS which is hard-float ABI distro. I used distro provided LLVM 3.0 and configured GHC with:

./configure --with-llc=/usr/bin/llc-3.0 --with-opt=/usr/bin/opt-3.0

Also the testsuite results run by: make THREADS=2 WAY="normal threaded1 threaded2" are here: OVERALL SUMMARY for test run started at Sun Jan 20 10:33:22 CET 2013 3400 total tests, which gave rise to 8325 test cases, of which 3 caused framework failures 3835 were skipped 4209 expected passes 151 had missing libraries 40 expected failures 4 unexpected passes 83 unexpected failures Unexpected passes: profiling/should_compile 2410 (normal) profiling/should_compile prof001 (normal) profiling/should_compile prof002 (normal) th TH_spliceE5_prof (normal) Unexpected failures: ../../libraries/base/tests/IO 4855 [exit code non-0] (threaded1) ../../libraries/base/tests/IO openFile008 [bad exit code] (normal,threaded1,threaded2) ../../libraries/hpc/tests/function subdir/tough2 [bad stderr] (normal) ../../libraries/hpc/tests/function tough [bad stderr] (threaded1,threaded2) ../../libraries/hpc/tests/ghc_ghci hpc_ghc_ghci [bad exit code] (normal) ../../libraries/template-haskell/tests dataToExpQUnit [exit code non-0] (normal) annotations/should_compile ann01 [exit code non-0] (normal) annotations/should_run annrun01 [exit code non-0] (normal,threaded1,threaded2) codeGen/should_compile jmp_tbl [exit code non-0] (normal) codeGen/should_compile massive_array [exit code non-0] (normal) driver T706 [bad exit code] (normal) ghc-api/T4891 T4891 [bad exit code] (normal) ghc-api/apirecomp001 apirecomp001 [bad exit code] (normal) ghc-e/should_run 2228 [bad exit code] (normal) ghc-e/should_run 3890 [bad stderr] (normal) ghc-e/should_run ghc-e001 [bad exit code] (normal) ghc-e/should_run ghc-e002 [bad exit code] (normal) ghc-e/should_run ghc-e003 [bad exit code] (normal) ghc-e/should_run ghc-e004 [bad stderr] (normal) ghc-e/should_run ghc-e005 [bad stderr] (normal) ghci/linking ghcilink001 [bad exit code] (normal) ghci/linking ghcilink002 [bad exit code] (normal) ghci/linking ghcilink003 [bad exit code] (normal) ghci/linking ghcilink004 [bad exit code] (normal) ghci/linking ghcilink005 [bad exit code] (normal) ghci/linking ghcilink006 [bad exit code] (normal) ghci/prog004 ghciprog004 [bad exit code] (normal) ghci/scripts ghci024 [bad exit code] (normal) ghci/scripts ghci037 [bad exit code] (normal) ghci/should_run 3171 [bad stdout] (normal) perf/compiler T1969 [stat not good enough] (normal) perf/compiler T3064 [stat not good enough] (normal) perf/compiler T4801 [stat not good enough] (normal) perf/compiler T5321FD [stat not good enough] (normal) perf/compiler T5321Fun [stat not good enough] (normal) perf/compiler T5631 [stat not good enough] (normal) perf/compiler T5642 [stat not good enough] (normal) perf/compiler T5837 [stat not good enough] (normal) perf/compiler T783 [stat not good enough] (normal) perf/compiler parsing001 [stat not good enough] (normal) plugins plugins01 [bad exit code] (normal) plugins plugins05 [exit code non-0] (normal,threaded1,threaded2) plugins plugins06 [exit code non-0] (normal,threaded1) programs/barton-mangler-bug barton-mangler-bug [exit code non-0] (threaded2) programs/joao-circular joao-circular [exit code non-0] (normal,threaded1,threaded2) quasiquotation/T4491 T4491 [exit code non-0] (normal,threaded1,threaded2) quasiquotation/qq007 qq007 [exit code non-0] (normal) rts 3424 [exit code non-0] (normal,threaded1) rts T2615 [bad exit code] (normal,threaded1,threaded2) rts derefnull [bad exit code] (threaded2) safeHaskell/flags Flags02 [exit code non-0] (normal) th T2700 [exit code non-0] (normal) th T4135 [exit code non-0] (normal) th T4188 [exit code non-0] (normal) th T5037 [exit code non-0] (normal) th T5362 [exit code non-0] (normal) th TH_Depends [bad exit code] (normal) th TH_PromotedList [exit code non-0] (normal) th TH_RichKinds2 [exit code non-0] (normal) th TH_reifyDecl1 [exit code non-0] (normal) th TH_reifyDecl2 [exit code non-0] (normal) th TH_reifyInstances [exit code non-0] (normal) th TH_reifyMkName [exit code non-0] (normal) th TH_repGuard [exit code non-0] (normal) th TH_repPrim [exit code non-0] (normal) th TH_repPrim2 [exit code non-0] (normal) th TH_repUnboxedTuples [exit code non-0] (normal) th TH_unresolvedInfix [exit code non-0] (normal) So definitely something is working on ARM/Linux. Karel

Stephen Paul Weber

1:39 p.m.

Somebody claiming to be Karel Gardas wrote:

...

I just build 7.6.1 release on my ubuntu 12.04.1 LTS which is hard-float ABI distro. I used distro provided LLVM 3.0 and configured GHC with:

Please keep in mind that GHC HEAD is completely different beast as there is new codegen put on by defaul there and LLVM codegen is not working correctly with it yet.

Oh? If LLVM codegen is broken in HEAD, that would explain why it's not working for ARM :) Hopefully I can get it working soon with at least an unregistered build. I have to build HEAD, since I'm doing cross-compiling. -- Stephen Paul Weber, @singpolyma See http://singpolyma.net for how I prefer to be contacted edition right joseph

Karel Gardas

1:50 p.m.

On 01/20/13 07:39 PM, Stephen Paul Weber wrote:

...

Somebody claiming to be Karel Gardas wrote:

...
I just build 7.6.1 release on my ubuntu 12.04.1 LTS which is hard-float ABI distro. I used distro provided LLVM 3.0 and configured GHC with:

Please keep in mind that GHC HEAD is completely different beast as there is new codegen put on by defaul there and LLVM codegen is not working correctly with it yet.

Oh? If LLVM codegen is broken in HEAD, that would explain why it's not working for ARM :) Hopefully I can get it working soon with at least an unregistered build. I have to build HEAD, since I'm doing cross-compiling.

The receipt is simple, first try LLVM-based build on fast x86 machine (i.e. cd mk; cp build.mk.sample build.mk; edit to uncomment BuildFlavour = quick-llvm) and once it's working attempt LLVM-based (the only way) build on ARM. Also, forget unregisterised build, rather ask Austin how is it looking with his work on fixing LLVM codegen in HEAD. And a last note: please keep in mind that cross-compiling is supported only using NCG. LLVM is completely out of question now, so you will have some work here anyway. I don't think it'll be complicated, but certainly some hacking with passing target triplet down to LLVM, but IIRC you've already found that anyway... Karel

Simon Marlow

21 Jan 21 Jan

8:33 a.m.

On 19/01/13 07:32, Stephen Paul Weber wrote:

...

Somebody claiming to be Stephen Paul Weber wrote:

...
Somebody claiming to be Nathan Hüsken wrote:

...
Was that an registerised or unregisterised build? Did anyone succesfully build ghc on an arm system which produces non crashing executables?

Just finally got a BB10 device set up so I can test my cross-compiler on the ARM

I'm about to try a configuration with --enable-unregisterised to see if that helps.

make -r --no-print-directory -f ghc.mk phase=final all "inplace/bin/ghc-stage1" -static -H64m -O0 -fasm -package-name integer-simple-0.1.1.0 -hide-all-packages -i -ilibraries/integer-simple/. -ilibraries/integer-simple/dist-install/build -ilibraries/integer-simple/dist-install/build/autogen -Ilibraries/integer-simple/dist-install/build -Ilibraries/integer-simple/dist-install/build/autogen -Ilibraries/integer-simple/. -optP-include -optPlibraries/integer-simple/dist-install/build/autogen/cabal_macros.h -package ghc-prim-0.3.1.0 -package-name integer-simple -Wall -XHaskell98 -XCPP -XMagicHash -XBangPatterns -XUnboxedTuples -XForeignFunctionInterface -XUnliftedFFITypes -XNoImplicitPrelude -O -fasm -no-user-package-db -rtsopts -odir libraries/integer-simple/dist-install/build -hidir libraries/integer-simple/dist-install/build -stubdir libraries/integer-simple/dist-install/build -hisuf hi -osuf o -hcsuf hc -c libraries/integer-simple/./GHC/Integer/Type.hs -o libraries/integer-simple/dist-install/build/GHC/Integer/Type.o

when making flags consistent: Warning: Compiler unregisterised, so compiling via C /tmp/ghc25891_0/ghc25891_0.hc: In function 'c2pA_entry':

/tmp/ghc25891_0/ghc25891_0.hc:3691:1: warning: this decimal constant is unsigned only in ISO C90 [enabled by default]

/tmp/ghc25891_0/ghc25891_0.hc:3691:17: error: expected ')' before numeric constant make[1]: *** [libraries/integer-simple/dist-install/build/GHC/Integer/Type.o] Error 1 make: *** [all] Error 2

Strange, I didn't see this on my builds, which I think is the same as yours (GHC HEAD, cross-compiling for RPi with --enable-unregisterised). If you make a ticket with full details, I can try to reproduce. Cheers, Simon

Nathan Hüsken

24 Jan 24 Jan

9:52 a.m.

Hey, For me thinks have changed. With the current ghc HEAD and llvm version 3.2 I am able to do a registerised build for android! I have not tested much, but Hello World works. Regards, Nathan On 01/14/2013 06:15 PM, Nathan Hüsken wrote:

...

In a different thread (Error building ghc on raspberry pi):

On 01/08/2013 12:27 PM, Thijs Alkemade wrote:(...)

...
I did eventually finish building stage2, but the final executable

segfaulted on start.

...
I haven't investigated much why that happened, the days it takes to rebuild it just made me give up.

Was that an registerised or unregisterised build? Did anyone succesfully build ghc on an arm system which produces non crashing executables?

I am asking, because I build a arm-linux-androideabi cross compiler, but the executables crash. Only in an unregisterised build, they work.

So I wonder if it is a general arm problem or has to do with android.

Thanks! Nathan

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Stephen Paul Weber

9:58 a.m.

Somebody claiming to be Nathan Hüsken wrote:

...

Hey,

For me thinks have changed. With the current ghc HEAD and llvm version 3.2 I am able to do a registerised build for android!

Do you think it is specifically the 3.2 that made it work? -- Stephen Paul Weber, @singpolyma See http://singpolyma.net for how I prefer to be contacted edition right joseph

Nathan Hüsken

10:21 a.m.

On 01/24/2013 03:58 PM, Stephen Paul Weber wrote:

...

Somebody claiming to be Nathan Hüsken wrote:

...
Hey,

For me thinks have changed. With the current ghc HEAD and llvm version 3.2 I am able to do a registerised build for android!

Do you think it is specifically the 3.2 that made it work?

Yes. With llvm version 3.1 I was only able to get an unregisterised build to work. Stephen Blackheath found that out, see here: http://www.haskell.org/pipermail/iphone/2013-January/000212.html

Stephen Paul Weber

10:28 a.m.

Somebody claiming to be Nathan Hüsken wrote:

...

On 01/24/2013 03:58 PM, Stephen Paul Weber wrote:

...
Somebody claiming to be Nathan Hüsken wrote:

...
With the current ghc HEAD and llvm version 3.2 I am able to do a registerised build for android! Do you think it is specifically the 3.2 that made it work?

Yes. With llvm version 3.1 I was only able to get an unregisterised build to work.

Did you have to hack the source ala http://hackage.haskell.org/trac/ghc/attachment/ticket/7621/unregistered-arm-... ?

...

Stephen Blackheath found that out, see here: http://www.haskell.org/pipermail/iphone/2013-January/000212.html

From that post, it seems like llvm-3.0 might also work? -- Stephen Paul Weber, @singpolyma See http://singpolyma.net for how I prefer to be contacted edition right joseph

Nathan Hüsken

10:41 a.m.

On 01/24/2013 04:28 PM, Stephen Paul Weber wrote:

...

Somebody claiming to be Nathan Hüsken wrote:

...
On 01/24/2013 03:58 PM, Stephen Paul Weber wrote:

...
Somebody claiming to be Nathan Hüsken wrote:

...
With the current ghc HEAD and llvm version 3.2 I am able to do a registerised build for android! Do you think it is specifically the 3.2 that made it work?

Yes. With llvm version 3.1 I was only able to get an unregisterised build to work.

Did you have to hack the source ala http://hackage.haskell.org/trac/ghc/attachment/ticket/7621/unregistered-arm-... ?

Not exactly, see the patch here: http://www.haskell.org/pipermail/ghc-devs/2013-January/000118.html and the changes to compiler/llvmGen/LlvmCodeGen/Ppr.hs

...

...
Stephen Blackheath found that out, see here: http://www.haskell.org/pipermail/iphone/2013-January/000212.html

From that post, it seems like llvm-3.0 might also work?

At the time of that post, ghc did not compile with 3.0 or 3.2. I have sticked to 3.2, and ghc compiles with it now. I do not know about 3.0.

Stephen Paul Weber

10:50 a.m.

Somebody claiming to be Nathan Hüsken wrote:

...

On 01/24/2013 04:28 PM, Stephen Paul Weber wrote:

...
...
...
Do you think it is specifically the 3.2 that made it work? Yes. With llvm version 3.1 I was only able to get an unregisterised build to work. http://hackage.haskell.org/trac/ghc/attachment/ticket/7621/unregistered-arm-... ?

Not exactly, see the patch here: http://www.haskell.org/pipermail/ghc-devs/2013-January/000118.html and the changes to compiler/llvmGen/LlvmCodeGen/Ppr.hs

Oh, man, the fact that I don't have that setting for QNX is probably not doing me any favours... How the heck am I supposed to figure out what that string should be? :( That said... how did you get an unregisterised build to work with an LLVM backend? Everything I've seen in the code implied that the moment you are unregisteried, it uses via-C... Which is what my above patch is primarily about. -- Stephen Paul Weber, @singpolyma See http://singpolyma.net for how I prefer to be contacted edition right joseph

Karel Gardas

11:04 a.m.

On 01/24/13 04:50 PM, Stephen Paul Weber wrote:

...

Somebody claiming to be Nathan Hüsken wrote:

...
On 01/24/2013 04:28 PM, Stephen Paul Weber wrote:

...
...
...
Do you think it is specifically the 3.2 that made it work? Yes. With llvm version 3.1 I was only able to get an unregisterised build to work. http://hackage.haskell.org/trac/ghc/attachment/ticket/7621/unregistered-arm-...

?

Not exactly, see the patch here: http://www.haskell.org/pipermail/ghc-devs/2013-January/000118.html and the changes to compiler/llvmGen/LlvmCodeGen/Ppr.hs

Oh, man, the fact that I don't have that setting for QNX is probably not doing me any favours...

IIRC it's more about optimization, i.e. proper data type alignment.

...

How the heck am I supposed to figure out what that string should be? :(

Described here: http://llvm.org/docs/LangRef.html#data-layout -- for LLVM 3.3. General rule, I would start with what Linux requires and check from that.

...

That said... how did you get an unregisterised build to work with an LLVM backend? Everything I've seen in the code implied that the moment you are unregisteried, it uses via-C... Which is what my above patch is primarily about.

IMHO Nathan is using registerised build. Nathan correct me please if I'm wrong as I'd like to also give your Android work a try in the future (being Android user myself...) Karel

Nathan Hüsken

11:59 a.m.

On 01/24/2013 05:04 PM, Karel Gardas wrote:

...

On 01/24/13 04:50 PM, Stephen Paul Weber wrote:

...
Somebody claiming to be Nathan Hüsken wrote:

...
On 01/24/2013 04:28 PM, Stephen Paul Weber wrote:

...
...
...
Do you think it is specifically the 3.2 that made it work? Yes. With llvm version 3.1 I was only able to get an unregisterised build to work. http://hackage.haskell.org/trac/ghc/attachment/ticket/7621/unregistered-arm-...

?

Not exactly, see the patch here: http://www.haskell.org/pipermail/ghc-devs/2013-January/000118.html and the changes to compiler/llvmGen/LlvmCodeGen/Ppr.hs

Oh, man, the fact that I don't have that setting for QNX is probably not doing me any favours...

IIRC it's more about optimization, i.e. proper data type alignment.

...
How the heck am I supposed to figure out what that string should be? :(

Described here: http://llvm.org/docs/LangRef.html#data-layout -- for LLVM 3.3. General rule, I would start with what Linux requires and check from that.

...
That said... how did you get an unregisterised build to work with an LLVM backend? Everything I've seen in the code implied that the moment you are unregisteried, it uses via-C... Which is what my above patch is primarily about.

IMHO Nathan is using registerised build. Nathan correct me please if I'm wrong as I'd like to also give your Android work a try in the future (being Android user myself...)

Yes, that is correct. registerised with llvm 3.2.

Stephen Paul Weber

11:51 a.m.

Somebody claiming to be Stephen Paul Weber wrote:

...

Somebody claiming to be Nathan Hüsken wrote:

...
On 01/24/2013 04:28 PM, Stephen Paul Weber wrote:

...
...
...
Do you think it is specifically the 3.2 that made it work? Yes. With llvm version 3.1 I was only able to get an unregisterised build to work. http://hackage.haskell.org/trac/ghc/attachment/ticket/7621/unregistered-arm-... ?

Not exactly, see the patch here: http://www.haskell.org/pipermail/ghc-devs/2013-January/000118.html and the changes to compiler/llvmGen/LlvmCodeGen/Ppr.hs

Oh, man, the fact that I don't have that setting for QNX is probably not doing me any favours...

I tried the following: diff --git a/compiler/llvmGen/LlvmCodeGen/Ppr.hs b/compiler/llvmGen/LlvmCodeGen/Ppr.hs index 218870a..a583ffc 100644 --- a/compiler/llvmGen/LlvmCodeGen/Ppr.hs +++ b/compiler/llvmGen/LlvmCodeGen/Ppr.hs @@ -58,6 +58,9 @@ moduleLayout = sdocWithPlatform $ \platform -> Platform { platformArch = ArchARM {}, platformOS = OSLinux } -> text "target datalayout = \"e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:64:128-a0:0:64-n32\"" $+$ text "target triple = \"arm-unknown-linux-gnueabi\"" + Platform { platformArch = ArchARM {}, platformOS = OSQNXNTO } -> + text "target datalayout = \"e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:64:128-a0:0:64-n32\"" + $+$ text "target triple = \"arm-unknown-nto-qnx8.0.0eabi\"" _ -> -- FIX: Other targets empty Doing a registered build with llvm-3.0 I eventually get: "inplace/bin/ghc-stage1" -o utils/hsc2hs/dist-install/build/tmp/hsc2hs -static -H64m -O0 -fllvm -hide-all-packages -i -iutils/hsc2hs/. -iutils/hsc2hs/dist-install/build -iutils/hsc2hs/dist-install/build/autogen -Iutils/hsc2hs/dist-install/build -Iutils/hsc2hs/dist-install/build/autogen -optP-include -optPutils/hsc2hs/dist-install/build/autogen/cabal_macros.h -package base-4.7.0.0 -package containers-0.5.0.0 -package directory-1.2.0.1 -package filepath-1.3.0.2 -package process-1.2.0.0 -XHaskell98 -XCPP -XForeignFunctionInterface -no-user-package-db -rtsopts -odir utils/hsc2hs/dist-install/build -hidir utils/hsc2hs/dist-install/build -stubdir utils/hsc2hs/dist-install/build -hisuf hi -osuf o -hcsuf hc utils/hsc2hs/dist-install/build/Main.o utils/hsc2hs/dist-install/build/HSCParser.o utils/hsc2hs/dist-install/build/DirectCodegen.o utils/hsc2hs/dist-install/build/CrossCodegen.o utils/hsc2hs/dist-install/build/UtilsCodegen.o utils/hsc2hs/dist-install/build/Common.o utils/hsc2hs/dist-install/build/C.o utils/hsc2hs/dist-install/build/Flags.o utils/hsc2hs/dist-install/build/Paths_hsc2hs.o /home/singpolyma/src/ghc-qnx-nto-arm/libraries/unix/dist-install/build/libHSunix-2.6.1.0.a(Signals.o): In function `c4Uj_info': ghc23292_0.c:(.text+0x20d4): undefined reference to `__aeabi_memcpy' /home/singpolyma/src/ghc-qnx-nto-arm/libraries/unix/dist-install/build/libHSunix-2.6.1.0.a(Signals.o): In function `c4XO_info': ghc23292_0.c:(.text+0x248c): undefined reference to `__aeabi_memcpy' /home/singpolyma/src/ghc-qnx-nto-arm/libraries/base/dist-install/build/libHSbase-4.7.0.0.a(Buffer.o): In function `c2Xe_info': /tmp/ghc20698_0/ghc20698_0.bc:(.text+0x2558): undefined reference to `__aeabi_memmove' /home/singpolyma/src/ghc-qnx-nto-arm/libraries/base/dist-install/build/libHSbase-4.7.0.0.a(Internals.o): In function `c7HG_info': /tmp/ghc21290_0/ghc21290_0.bc:(.text+0x5e70): undefined reference to `__aeabi_memmove' /home/singpolyma/src/ghc-qnx-nto-arm/libraries/base/dist-install/build/libHSbase-4.7.0.0.a(Text.o): In function `base_GHCziIOziHandleziText_zdwccall_info': /tmp/ghc21310_0/ghc21310_0.bc:(.text+0x378): undefined reference to `__aeabi_memcpy' /home/singpolyma/src/ghc-qnx-nto-arm/libraries/base/dist-install/build/libHSbase-4.7.0.0.a(Text.o): In function `c7s6_info': /tmp/ghc21310_0/ghc21310_0.bc:(.text+0x4c4): undefined reference to `__aeabi_memcpy' /home/singpolyma/src/ghc-qnx-nto-arm/libraries/base/dist-install/build/libHSbase-4.7.0.0.a(Text.o): In function `c9cs_info': /tmp/ghc21310_0/ghc21310_0.bc:(.text+0x7588): undefined reference to `__aeabi_memcpy' /home/singpolyma/src/ghc-qnx-nto-arm/libraries/base/dist-install/build/libHSbase-4.7.0.0.a(Text.o): In function `c9nS_info': /tmp/ghc21310_0/ghc21310_0.bc:(.text+0x8318): undefined reference to `__aeabi_memcpy' /tmp/ghc21310_0/ghc21310_0.bc:(.text+0x83e4): undefined reference to `__aeabi_memcpy' /home/singpolyma/src/ghc-qnx-nto-arm/libraries/base/dist-install/build/libHSbase-4.7.0.0.a(Text.o):/tmp/ghc21310_0/ghc21310_0.bc:(.text+0xa2ec): more undefined references to `__aeabi_memcpy' follow /home/singpolyma/src/ghc-qnx-nto-arm/libraries/base/dist-install/build/libHSbase-4.7.0.0.a(Array.o): In function `c1Uf_info': /tmp/ghc20805_0/ghc20805_0.bc:(.text+0x5a8): undefined reference to `__aeabi_memmove' /home/singpolyma/src/ghc-qnx-nto-arm/libraries/base/dist-install/build/libHSbase-4.7.0.0.a(Array.o): In function `c1Wm_info': /tmp/ghc20805_0/ghc20805_0.bc:(.text+0x7dc): undefined reference to `__aeabi_memcpy' /home/singpolyma/src/ghc-qnx-nto-arm/libraries/base/dist-install/build/libHSbase-4.7.0.0.a(Utils.o): In function `c205_info': /tmp/ghc20795_0/ghc20795_0.bc:(.text+0xcf8): undefined reference to `__aeabi_memcpy' /home/singpolyma/src/ghc-qnx-nto-arm/libraries/base/dist-install/build/libHSbase-4.7.0.0.a(Utils.o): In function `c21k_info': /tmp/ghc20795_0/ghc20795_0.bc:(.text+0xe30): undefined reference to `__aeabi_memmove' /home/singpolyma/src/ghc-qnx-nto-arm/libraries/base/dist-install/build/libHSbase-4.7.0.0.a(Internals.o): In function `c89F_info': ghc21121_0.c:(.text+0x7a20): undefined reference to `__aeabi_memcpy' /home/singpolyma/src/ghc-qnx-nto-arm/libraries/base/dist-install/build/libHSbase-4.7.0.0.a(Array.o): In function `c4uI_info': /tmp/ghc21061_0/ghc21061_0.bc:(.text+0x23e0): undefined reference to `__aeabi_memcpy' /home/singpolyma/src/ghc-qnx-nto-arm/libraries/base/dist-install/build/libHSbase-4.7.0.0.a(Array.o): In function `c4DF_info': /tmp/ghc21061_0/ghc21061_0.bc:(.text+0x2e28): undefined reference to `__aeabi_memmove' /home/singpolyma/src/ghc-qnx-nto-arm/libraries/base/dist-install/build/libHSbase-4.7.0.0.a(Array.o): In function `c4Qo_info': /tmp/ghc21061_0/ghc21061_0.bc:(.text+0x33cc): undefined reference to `__aeabi_memcpy' /home/singpolyma/src/ghc-qnx-nto-arm/libraries/base/dist-install/build/libHSbase-4.7.0.0.a(Array.o): In function `c59t_info': /tmp/ghc21061_0/ghc21061_0.bc:(.text+0x4108): undefined reference to `__aeabi_memcpy' /home/singpolyma/src/ghc-qnx-nto-arm/libraries/base/dist-install/build/libHSbase-4.7.0.0.a(Array.o): In function `c58Y_info': /tmp/ghc21061_0/ghc21061_0.bc:(.text+0x42d4): undefined reference to `__aeabi_memcpy' collect2: ld returned 1 exit status make[1]: *** [utils/hsc2hs/dist-install/build/tmp/hsc2hs] Error 1 make: *** [all] Error 2 So... it can't find memcpy for some reason? I'm about to try with llvm-3.2 to see if that's different. -- Stephen Paul Weber, @singpolyma See http://singpolyma.net for how I prefer to be contacted edition right joseph

Nathan Hüsken

12:06 p.m.

On 01/24/2013 05:51 PM, Stephen Paul Weber wrote: (...)

...

So... it can't find memcpy for some reason?

I'm about to try with llvm-3.2 to see if that's different.

I had similar problems with mkfifo. I believe the reason was, that in the android nkd mkfifo is inlined. The solution for me was to wrap mkfifo (in a function I called __mkfifo) and used that one from the ffi instead. But the symbol not found is __aeabi_memcpy, not memcpy itself ... I can not find __aeabi_memcpy in the ghc source ... Maybe it is not linking some required library?

Stephen Paul Weber

12:28 p.m.

Somebody claiming to be Nathan Hüsken wrote:

...

On 01/24/2013 05:51 PM, Stephen Paul Weber wrote: (...)

...
So... it can't find memcpy for some reason?

I'm about to try with llvm-3.2 to see if that's different.

The solution for me was to wrap mkfifo (in a function I called __mkfifo) and used that one from the ffi instead.

Right, I see things around on the web about people doing similar stuff.

...

But the symbol not found is __aeabi_memcpy, not memcpy itself ... I can not find __aeabi_memcpy in the ghc source ... Maybe it is not linking some required library?

I'm not sure. Most curious is that this has not come up before in any of my other ARM-build attempts (which produced less-than-working code, but suceeded in compiling). -- Stephen Paul Weber, @singpolyma See http://singpolyma.net for how I prefer to be contacted edition right joseph

Stephen Paul Weber

12:51 p.m.

Somebody claiming to be Stephen Paul Weber wrote:

...

Somebody claiming to be Nathan Hüsken wrote:

...
But the symbol not found is __aeabi_memcpy, not memcpy itself ... I can not find __aeabi_memcpy in the ghc source ... Maybe it is not linking some required library?

I'm not sure. Most curious is that this has not come up before in any of my other ARM-build attempts (which produced less-than-working code, but suceeded in compiling).

This seems to be a general ARM thing: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka3934.html ... so not sure why I'm getting it and no one else is. -- Stephen Paul Weber, @singpolyma See http://singpolyma.net for how I prefer to be contacted edition right joseph

Karel Gardas

1:01 p.m.

On 01/24/13 06:51 PM, Stephen Paul Weber wrote:

...

Somebody claiming to be Stephen Paul Weber wrote:

...
Somebody claiming to be Nathan Hüsken wrote:

...
But the symbol not found is __aeabi_memcpy, not memcpy itself ... I can not find __aeabi_memcpy in the ghc source ... Maybe it is not linking some required library?

I'm not sure. Most curious is that this has not come up before in any of my other ARM-build attempts (which produced less-than-working code, but suceeded in compiling).

This seems to be a general ARM thing: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka3934.html ... so not sure why I'm getting it and no one else is.

Copy your last ghc-stage1 invocation step, add "-v -keep-tmp-files" and see what it'll execute for you. At least you should see libraries which are going into the link process. Then write C hello world, compile and link it and see what's going inside linking and compare with ghc. I guess some lib will be missing in case of ghc linking phase so you'll need to add it either into mk/build.mk appropriate option (E.g. -optl-l<your lib>) or just hack DynFlags.hs to include this for you. Karel

Karel Gardas

12:48 p.m.

On 01/24/13 05:51 PM, Stephen Paul Weber wrote:

...

Doing a registered build with llvm-3.0 I eventually get:

"inplace/bin/ghc-stage1" -o utils/hsc2hs/dist-install/build/tmp/hsc2hs -static -H64m -O0 -fllvm -hide-all-packages -i -iutils/hsc2hs/. -iutils/hsc2hs/dist-install/build -iutils/hsc2hs/dist-install/build/autogen -Iutils/hsc2hs/dist-install/build -Iutils/hsc2hs/dist-install/build/autogen -optP-include -optPutils/hsc2hs/dist-install/build/autogen/cabal_macros.h -package base-4.7.0.0 -package containers-0.5.0.0 -package directory-1.2.0.1 -package filepath-1.3.0.2 -package process-1.2.0.0 -XHaskell98 -XCPP -XForeignFunctionInterface -no-user-package-db -rtsopts -odir utils/hsc2hs/dist-install/build -hidir utils/hsc2hs/dist-install/build -stubdir utils/hsc2hs/dist-install/build -hisuf hi -osuf o -hcsuf hc utils/hsc2hs/dist-install/build/Main.o utils/hsc2hs/dist-install/build/HSCParser.o utils/hsc2hs/dist-install/build/DirectCodegen.o utils/hsc2hs/dist-install/build/CrossCodegen.o utils/hsc2hs/dist-install/build/UtilsCodegen.o utils/hsc2hs/dist-install/build/Common.o utils/hsc2hs/dist-install/build/C.o utils/hsc2hs/dist-install/build/Flags.o utils/hsc2hs/dist-install/build/Paths_hsc2hs.o /home/singpolyma/src/ghc-qnx-nto-arm/libraries/unix/dist-install/build/libHSunix-2.6.1.0.a(Signals.o): In function `c4Uj_info': ghc23292_0.c:(.text+0x20d4): undefined reference to `__aeabi_memcpy' /home/singpolyma/src/ghc-qnx-nto-arm/libraries/unix/dist-install/build/libHSunix-2.6.1.0.a(Signals.o): In function `c4XO_info': ghc23292_0.c:(.text+0x248c): undefined reference to `__aeabi_memcpy' /home/singpolyma/src/ghc-qnx-nto-arm/libraries/base/dist-install/build/libHSbase-4.7.0.0.a(Buffer.o): In function `c2Xe_info': /tmp/ghc20698_0/ghc20698_0.bc:(.text+0x2558): undefined reference to `__aeabi_memmove' /home/singpolyma/src/ghc-qnx-nto-arm/libraries/base/dist-install/build/libHSbase-4.7.0.0.a(Internals.o): In function `c7HG_info': /tmp/ghc21290_0/ghc21290_0.bc:(.text+0x5e70): undefined reference to `__aeabi_memmove' /home/singpolyma/src/ghc-qnx-nto-arm/libraries/base/dist-install/build/libHSbase-4.7.0.0.a(Text.o): In function `base_GHCziIOziHandleziText_zdwccall_info': /tmp/ghc21310_0/ghc21310_0.bc:(.text+0x378): undefined reference to `__aeabi_memcpy' /home/singpolyma/src/ghc-qnx-nto-arm/libraries/base/dist-install/build/libHSbase-4.7.0.0.a(Text.o): In function `c7s6_info': /tmp/ghc21310_0/ghc21310_0.bc:(.text+0x4c4): undefined reference to `__aeabi_memcpy' /home/singpolyma/src/ghc-qnx-nto-arm/libraries/base/dist-install/build/libHSbase-4.7.0.0.a(Text.o): In function `c9cs_info': /tmp/ghc21310_0/ghc21310_0.bc:(.text+0x7588): undefined reference to `__aeabi_memcpy' /home/singpolyma/src/ghc-qnx-nto-arm/libraries/base/dist-install/build/libHSbase-4.7.0.0.a(Text.o): In function `c9nS_info': /tmp/ghc21310_0/ghc21310_0.bc:(.text+0x8318): undefined reference to `__aeabi_memcpy' /tmp/ghc21310_0/ghc21310_0.bc:(.text+0x83e4): undefined reference to `__aeabi_memcpy' /home/singpolyma/src/ghc-qnx-nto-arm/libraries/base/dist-install/build/libHSbase-4.7.0.0.a(Text.o):/tmp/ghc21310_0/ghc21310_0.bc:(.text+0xa2ec): more undefined references to `__aeabi_memcpy' follow /home/singpolyma/src/ghc-qnx-nto-arm/libraries/base/dist-install/build/libHSbase-4.7.0.0.a(Array.o): In function `c1Uf_info': /tmp/ghc20805_0/ghc20805_0.bc:(.text+0x5a8): undefined reference to `__aeabi_memmove' /home/singpolyma/src/ghc-qnx-nto-arm/libraries/base/dist-install/build/libHSbase-4.7.0.0.a(Array.o): In function `c1Wm_info': /tmp/ghc20805_0/ghc20805_0.bc:(.text+0x7dc): undefined reference to `__aeabi_memcpy' /home/singpolyma/src/ghc-qnx-nto-arm/libraries/base/dist-install/build/libHSbase-4.7.0.0.a(Utils.o): In function `c205_info': /tmp/ghc20795_0/ghc20795_0.bc:(.text+0xcf8): undefined reference to `__aeabi_memcpy' /home/singpolyma/src/ghc-qnx-nto-arm/libraries/base/dist-install/build/libHSbase-4.7.0.0.a(Utils.o): In function `c21k_info': /tmp/ghc20795_0/ghc20795_0.bc:(.text+0xe30): undefined reference to `__aeabi_memmove' /home/singpolyma/src/ghc-qnx-nto-arm/libraries/base/dist-install/build/libHSbase-4.7.0.0.a(Internals.o): In function `c89F_info': ghc21121_0.c:(.text+0x7a20): undefined reference to `__aeabi_memcpy' /home/singpolyma/src/ghc-qnx-nto-arm/libraries/base/dist-install/build/libHSbase-4.7.0.0.a(Array.o): In function `c4uI_info': /tmp/ghc21061_0/ghc21061_0.bc:(.text+0x23e0): undefined reference to `__aeabi_memcpy' /home/singpolyma/src/ghc-qnx-nto-arm/libraries/base/dist-install/build/libHSbase-4.7.0.0.a(Array.o): In function `c4DF_info': /tmp/ghc21061_0/ghc21061_0.bc:(.text+0x2e28): undefined reference to `__aeabi_memmove' /home/singpolyma/src/ghc-qnx-nto-arm/libraries/base/dist-install/build/libHSbase-4.7.0.0.a(Array.o): In function `c4Qo_info': /tmp/ghc21061_0/ghc21061_0.bc:(.text+0x33cc): undefined reference to `__aeabi_memcpy' /home/singpolyma/src/ghc-qnx-nto-arm/libraries/base/dist-install/build/libHSbase-4.7.0.0.a(Array.o): In function `c59t_info': /tmp/ghc21061_0/ghc21061_0.bc:(.text+0x4108): undefined reference to `__aeabi_memcpy' /home/singpolyma/src/ghc-qnx-nto-arm/libraries/base/dist-install/build/libHSbase-4.7.0.0.a(Array.o): In function `c58Y_info': /tmp/ghc21061_0/ghc21061_0.bc:(.text+0x42d4): undefined reference to `__aeabi_memcpy' collect2: ld returned 1 exit status make[1]: *** [utils/hsc2hs/dist-install/build/tmp/hsc2hs] Error 1 make: *** [all] Error 2

So... it can't find memcpy for some reason?

I'm about to try with llvm-3.2 to see if that's different.

I don't think different llvm will help here. This is purely linker issue. Somehow you link with different set of libraries probably. Anyway it looks like: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka3934.html -- this function is part of common ARM EABI so it should be implemented by your C compiler tool-chain. You just need to find out where it is and how you may use it. Karel

Stephen Paul Weber

1 p.m.

Somebody claiming to be Karel Gardas wrote:

...

On 01/24/13 05:51 PM, Stephen Paul Weber wrote:

...
Doing a registered build with llvm-3.0 I eventually get: In function `c58Y_info': /tmp/ghc21061_0/ghc21061_0.bc:(.text+0x42d4): undefined reference to `__aeabi_memcpy' collect2: ld returned 1 exit status make[1]: *** [utils/hsc2hs/dist-install/build/tmp/hsc2hs] Error 1 make: *** [all] Error 2

This is purely linker issue. Somehow you link with different set of libraries probably. Anyway it looks like: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka3934.html -- this function is part of common ARM EABI so it should be implemented by your C compiler tool-chain. You just need to find out where it is and how you may use it.

So, not sure on the right solution, but when I add -lcaps then the linker errors go away and I can build executables. Unfortunately, when I try to run any of them on a device, I get a segfault, just as I always did with registerised cross-builds for ARM... this with both llvm-3.0 and llvm-3.2 :( -- Stephen Paul Weber, @singpolyma See http://singpolyma.net for how I prefer to be contacted edition right joseph

Nathan Hüsken

1:02 p.m.

On 01/24/2013 07:00 PM, Stephen Paul Weber wrote:

...

Somebody claiming to be Karel Gardas wrote:

...
On 01/24/13 05:51 PM, Stephen Paul Weber wrote:

...
Doing a registered build with llvm-3.0 I eventually get: In function `c58Y_info': /tmp/ghc21061_0/ghc21061_0.bc:(.text+0x42d4): undefined reference to `__aeabi_memcpy' collect2: ld returned 1 exit status make[1]: *** [utils/hsc2hs/dist-install/build/tmp/hsc2hs] Error 1 make: *** [all] Error 2

This is purely linker issue. Somehow you link with different set of libraries probably. Anyway it looks like: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka3934.html -- this function is part of common ARM EABI so it should be implemented by your C compiler tool-chain. You just need to find out where it is and how you may use it.

So, not sure on the right solution, but when I add -lcaps then the linker errors go away and I can build executables. Unfortunately, when I try to run any of them on a device, I get a segfault, just as I always did with registerised cross-builds for ARM... this with both llvm-3.0 and llvm-3.2

:(

Can you run it in gdb and loock what the backtrace looks like?

Stephen Paul Weber

1:09 p.m.

Somebody claiming to be Nathan Hüsken wrote:

...

On 01/24/2013 07:00 PM, Stephen Paul Weber wrote:

...
Somebody claiming to be Karel Gardas wrote:

...
On 01/24/13 05:51 PM, Stephen Paul Weber wrote: :(

Can you run it in gdb and loock what the backtrace looks like?

I can maybe get a core file and load it into gdb. I may try that soon. -- Stephen Paul Weber, @singpolyma See http://singpolyma.net for how I prefer to be contacted edition right joseph

Stephen Paul Weber

1:26 p.m.

Somebody claiming to be Nathan Hüsken wrote:

...

On 01/24/2013 07:00 PM, Stephen Paul Weber wrote:

...
...
On 01/24/13 05:51 PM, Stephen Paul Weber wrote: So, not sure on the right solution, but when I add -lcaps then the

Somebody claiming to be Karel Gardas wrote: linker errors go away and I can build executables. Unfortunately, when I try to run any of them on a device, I get a segfault, just as I always did with registerised cross-builds for ARM... this with both llvm-3.0 and llvm-3.2

:(

Can you run it in gdb and loock what the backtrace looks like?

[New pid 14037182 tid 1] Program terminated with signal 11, Segmentation fault. #0 0x08502000 in ?? () (gdb) bt #0 0x08502000 in ?? () #1 0x082ce4c4 in ?? () #2 0x082ce4c4 in ?? () Backtrace stopped: previous frame identical to this frame (corrupt stack?) (gdb) -- Stephen Paul Weber, @singpolyma See http://singpolyma.net for how I prefer to be contacted edition right joseph

Nathan Hüsken

1:28 p.m.

On 01/24/2013 07:26 PM, Stephen Paul Weber wrote:

...

Somebody claiming to be Nathan Hüsken wrote:

...
On 01/24/2013 07:00 PM, Stephen Paul Weber wrote:

...
...
On 01/24/13 05:51 PM, Stephen Paul Weber wrote: So, not sure on the right solution, but when I add -lcaps then the

Somebody claiming to be Karel Gardas wrote: linker errors go away and I can build executables. Unfortunately, when I try to run any of them on a device, I get a segfault, just as I always did with registerised cross-builds for ARM... this with both llvm-3.0 and llvm-3.2

:(

Can you run it in gdb and loock what the backtrace looks like?

[New pid 14037182 tid 1] Program terminated with signal 11, Segmentation fault. #0 0x08502000 in ?? () (gdb) bt #0 0x08502000 in ?? () #1 0x082ce4c4 in ?? () #2 0x082ce4c4 in ?? () Backtrace stopped: previous frame identical to this frame (corrupt stack?) (gdb)

Not very informative :). Did you compile with -debug? I remember I got a stack trace with gdb like this (when doing remote debugging) and got it cleaned up by loading the exectuable with "file". Maybe you have to do something like that to?

David Terei

2:44 p.m.

Hi all, Can people please file bugs about these issues when they are confirmed to some degree? Lots of ARM & LLVM stuff seems to just be floating around mailing lists.... much higher chance of me or someone else fixing if there are filed bug reports with test cases and/or patches attached. Austin and I also fixed a couple of LLVM related issues in the last 2 days or so, so hopefully that solved some of these. Top level bugs to link to when filing other bugs please: * GHC ARM support: http://hackage.haskell.org/trac/ghc/ticket/7623 * LLVM Cross compilation: http://hackage.haskell.org/trac/ghc/ticket/7610 * LLVM unregisterised issues: http://hackage.haskell.org/trac/ghc/ticket/7622 * LLVM bootstrap issues: http://hackage.haskell.org/trac/ghc/ticket/7590 Cheers, David On 24 January 2013 10:28, Nathan Hüsken wrote:

...

On 01/24/2013 07:26 PM, Stephen Paul Weber wrote:

...
Somebody claiming to be Nathan Hüsken wrote:

...
On 01/24/2013 07:00 PM, Stephen Paul Weber wrote:

...
...
On 01/24/13 05:51 PM, Stephen Paul Weber wrote: So, not sure on the right solution, but when I add -lcaps then the

Somebody claiming to be Karel Gardas wrote: linker errors go away and I can build executables. Unfortunately, when I try to run any of them on a device, I get a segfault, just as I always did with registerised cross-builds for ARM... this with both llvm-3.0 and llvm-3.2

:(

Can you run it in gdb and loock what the backtrace looks like?

[New pid 14037182 tid 1] Program terminated with signal 11, Segmentation fault. #0 0x08502000 in ?? () (gdb) bt #0 0x08502000 in ?? () #1 0x082ce4c4 in ?? () #2 0x082ce4c4 in ?? () Backtrace stopped: previous frame identical to this frame (corrupt stack?) (gdb)

Not very informative :). Did you compile with -debug? I remember I got a stack trace with gdb like this (when doing remote debugging) and got it cleaned up by loading the exectuable with "file". Maybe you have to do something like that to?

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Stephen Paul Weber

5:59 p.m.

Somebody claiming to be Nathan Hüsken wrote:

...

On 01/24/2013 07:26 PM, Stephen Paul Weber wrote:

...
Somebody claiming to be Nathan Hüsken wrote:

...
Can you run it in gdb and loock what the backtrace looks like? Did you compile with -debug? I remember I got a stack trace with gdb like this (when doing remote debugging) and got it cleaned up by loading the exectuable with "file". Maybe you have to do something like that to?

$ ntoarm-gdb --core=Main.core Main ... copyright and such ... [New pid 14336138 tid 1] warning: .dynamic section for "/home/singpolyma/bbndk/target_10_0_9_1673/qnx6/armle-v7/usr/lib/libEGL.so.1" is not at the expected address (wrong library or version mismatch?) warning: .dynamic section for "/home/singpolyma/bbndk/target_10_0_9_1673/qnx6/armle-v7/usr/lib/libGLESv2.so.1" is not at the expected address (wrong library or version mismatch?) Program terminated with signal 11, Segmentation fault. #0 0x08402000 in ?? () (gdb) bt #0 0x08402000 in ?? () #1 0x082de978 in stg_ap_p_fast () #2 0x082de978 in stg_ap_p_fast () Backtrace stopped: previous frame identical to this frame (corrupt stack?) -- Stephen Paul Weber, @singpolyma See http://singpolyma.net for how I prefer to be contacted edition right joseph

Nathan Hüsken

25 Jan 25 Jan

4:01 a.m.

On 01/24/2013 11:59 PM, Stephen Paul Weber wrote:

...

Somebody claiming to be Nathan Hüsken wrote:

...
On 01/24/2013 07:26 PM, Stephen Paul Weber wrote:

...
Somebody claiming to be Nathan Hüsken wrote:

...
Can you run it in gdb and loock what the backtrace looks like? Did you compile with -debug? I remember I got a stack trace with gdb like this (when doing remote debugging) and got it cleaned up by loading the exectuable with "file". Maybe you have to do something like that to?

$ ntoarm-gdb --core=Main.core Main ... copyright and such ...

[New pid 14336138 tid 1]

warning: .dynamic section for "/home/singpolyma/bbndk/target_10_0_9_1673/qnx6/armle-v7/usr/lib/libEGL.so.1" is not at the expected address (wrong library or version mismatch?)

warning: .dynamic section for "/home/singpolyma/bbndk/target_10_0_9_1673/qnx6/armle-v7/usr/lib/libGLESv2.so.1" is not at the expected address (wrong library or version mismatch?) Program terminated with signal 11, Segmentation fault. #0 0x08402000 in ?? () (gdb) bt #0 0x08402000 in ?? () #1 0x082de978 in stg_ap_p_fast () #2 0x082de978 in stg_ap_p_fast () Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Sorry, I can not help. All I can do is point you here: http://hackage.haskell.org/trac/ghc/wiki/Debugging/CompiledCode?redirectedfr... Regards, Nathan

Karel Gardas

26 Jan 26 Jan

2:04 p.m.

Now, the question is: does QNX use the same ABI as Linux on ARM? See ARM EABI notes in includes/stg/MachRegs.h Karel On 01/24/13 11:59 PM, Stephen Paul Weber wrote:

...

Somebody claiming to be Nathan Hüsken wrote:

...
On 01/24/2013 07:26 PM, Stephen Paul Weber wrote:

...
Somebody claiming to be Nathan Hüsken wrote:

...
Can you run it in gdb and loock what the backtrace looks like? Did you compile with -debug? I remember I got a stack trace with gdb like this (when doing remote debugging) and got it cleaned up by loading the exectuable with "file". Maybe you have to do something like that to?

$ ntoarm-gdb --core=Main.core Main ... copyright and such ...

[New pid 14336138 tid 1]

warning: .dynamic section for "/home/singpolyma/bbndk/target_10_0_9_1673/qnx6/armle-v7/usr/lib/libEGL.so.1" is not at the expected address (wrong library or version mismatch?)

warning: .dynamic section for "/home/singpolyma/bbndk/target_10_0_9_1673/qnx6/armle-v7/usr/lib/libGLESv2.so.1" is not at the expected address (wrong library or version mismatch?) Program terminated with signal 11, Segmentation fault. #0 0x08402000 in ?? () (gdb) bt #0 0x08402000 in ?? () #1 0x082de978 in stg_ap_p_fast () #2 0x082de978 in stg_ap_p_fast () Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Nathan Hüsken

24 Jan 24 Jan

11:58 a.m.

On 01/24/2013 04:50 PM, Stephen Paul Weber wrote:

...

Somebody claiming to be Nathan Hüsken wrote:

...
On 01/24/2013 04:28 PM, Stephen Paul Weber wrote:

...
...
...
Do you think it is specifically the 3.2 that made it work? Yes. With llvm version 3.1 I was only able to get an unregisterised build to work. http://hackage.haskell.org/trac/ghc/attachment/ticket/7621/unregistered-arm-...

?

Not exactly, see the patch here: http://www.haskell.org/pipermail/ghc-devs/2013-January/000118.html and the changes to compiler/llvmGen/LlvmCodeGen/Ppr.hs

Oh, man, the fact that I don't have that setting for QNX is probably not doing me any favours...

How the heck am I supposed to figure out what that string should be? :(

Do you mean the data layout? Actually, I have to admit I just copied it from arm linux.

...

That said... how did you get an unregisterised build to work with an LLVM backend? Everything I've seen in the code implied that the moment you are unregisteried, it uses via-C... Which is what my above patch is primarily about.

I ... it just worked :). I passed --enable-unregistered to configure and that did the trick. During building it always said "via-C", but it worked.

Simon Marlow

25 Jan 25 Jan

5:29 a.m.

On 24/01/13 16:58, Nathan Hüsken wrote:

...

On 01/24/2013 04:50 PM, Stephen Paul Weber wrote:

...
Somebody claiming to be Nathan Hüsken wrote:

...
On 01/24/2013 04:28 PM, Stephen Paul Weber wrote:

...
...
...
Do you think it is specifically the 3.2 that made it work? Yes. With llvm version 3.1 I was only able to get an unregisterised build to work. http://hackage.haskell.org/trac/ghc/attachment/ticket/7621/unregistered-arm-...

?

Not exactly, see the patch here: http://www.haskell.org/pipermail/ghc-devs/2013-January/000118.html and the changes to compiler/llvmGen/LlvmCodeGen/Ppr.hs

Oh, man, the fact that I don't have that setting for QNX is probably not doing me any favours...

How the heck am I supposed to figure out what that string should be? :(

Do you mean the data layout? Actually, I have to admit I just copied it from arm linux.

...
That said... how did you get an unregisterised build to work with an LLVM backend? Everything I've seen in the code implied that the moment you are unregisteried, it uses via-C... Which is what my above patch is primarily about.

I ... it just worked :). I passed --enable-unregistered to configure and that did the trick. During building it always said "via-C", but it worked.

You're not using LLVM, due to #7622. I'll push the trivial patch to fix that as soon as it has validated here. Cheers, Simon

4498

Age (days ago)

4510

Last active (days ago)

List overview

Download

38 comments

7 participants

participants (7)

Ben Gamari
David Terei
Karel Gardas
Nathan Hüsken
Simon Marlow
Stefan Kersten
Stephen Paul Weber