Re: any successfull ghc registerised builds on arm?
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?) ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: any successfull ghc registerised builds on arm?
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?redirectedfrom=DebuggingGhcCrashes Regards, Nathan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: any successfull ghc registerised builds on arm?
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-llvm-hack.patch ? 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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: any successfull ghc registerised builds on arm?
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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: any successfull ghc registerised builds on arm?
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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: any successfull ghc registerised builds on arm?
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-llvm-hack.patch ? 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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: any successfull ghc registerised builds on arm?
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-llvm-hack.patch ? 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. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: any successfull ghc registerised builds on arm?
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-llvm-hack.patch ? 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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: any successfull ghc registerised builds on arm?
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-llvm-hack.patch ? 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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: any successfull ghc registerised builds on arm?
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-llvm-hack.patch
?
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'
Re: any successfull ghc registerised builds on arm?
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-llvm-hack.patch ? 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. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: any successfull ghc registerised builds on arm?
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-llvm-hack.patch ? 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. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: any successfull ghc registerised builds on arm?
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? ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: any successfull ghc registerised builds on arm?
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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: any successfull ghc registerised builds on arm?
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':
Re: any successfull ghc registerised builds on arm?
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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: any successfull ghc registerised builds on arm?
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 -lcapsthen 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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: any successfull ghc registerised builds on arm?
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-lyour lib) or just hack DynFlags.hs to include this for you. Karel ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: any successfull ghc registerised builds on arm?
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 -lcapsthen 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? ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: any successfull ghc registerised builds on arm?
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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: any successfull ghc registerised builds on arm?
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: So, not sure on the right solution, but when I add -lcapsthen 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? [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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: any successfull ghc registerised builds on arm?
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: Somebody claiming to be Karel Gardas wrote: On 01/24/13 05:51 PM, Stephen Paul Weber wrote: So, not sure on the right solution, but when I add -lcapsthen 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? [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
Re: any successfull ghc registerised builds on arm?
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 nathan.hues...@posteo.de 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: Somebody claiming to be Karel Gardas wrote: On 01/24/13 05:51 PM, Stephen Paul Weber wrote: So, not sure on the right solution, but when I add -lcapsthen 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? [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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: any successfull ghc registerised builds on arm?
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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: any successfull ghc registerised builds on arm?
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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: any successfull ghc registerised builds on arm?
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) thTH_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/apirecomp001apirecomp001 [bad exit code] (normal) ghc-e/should_run2228 [bad exit code] (normal) ghc-e/should_run3890 [bad stderr] (normal) ghc-e/should_runghc-e001 [bad exit code] (normal) ghc-e/should_runghc-e002 [bad exit code] (normal) ghc-e/should_runghc-e003 [bad exit code] (normal) ghc-e/should_runghc-e004 [bad stderr] (normal) ghc-e/should_runghc-e005 [bad stderr] (normal) ghci/linkingghcilink001 [bad exit code] (normal) ghci/linkingghcilink002 [bad exit code] (normal) ghci/linkingghcilink003 [bad exit code] (normal) ghci/linkingghcilink004 [bad exit code] (normal) ghci/linkingghcilink005 [bad exit code] (normal) ghci/linkingghcilink006 [bad exit code] (normal) ghci/prog004ghciprog004 [bad exit code] (normal) ghci/scriptsghci024 [bad exit code] (normal) ghci/scriptsghci037 [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/T4491T4491 [exit code non-0] (normal,threaded1,threaded2) quasiquotation/qq007qq007 [exit code non-0] (normal) rts 3424 [exit code non-0] (normal,threaded1) rts T2615 [bad exit code] (normal,threaded1,threaded2) rts
Re: any successfull ghc registerised builds on arm?
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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: any successfull ghc registerised builds on arm?
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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: any successfull ghc registerised builds on arm?
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? ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: any successfull ghc registerised builds on arm?
Somebody claiming to be Ben Gamari wrote: Stephen Paul Weber singpol...@singpolyma.net 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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: any successfull ghc registerised builds on arm?
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
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: any successfull ghc registerised builds on arm?
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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: any successfull ghc registerised builds on arm?
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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: any successfull ghc registerised builds on arm?
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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: any successfull ghc registerised builds on arm?
hi nathan, On Jan 14, 2013, at 6:15 PM, Nathan Hüsken nathan.hues...@posteo.de 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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: any successfull ghc registerised builds on arm?
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 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: any successfull ghc registerised builds on arm?
(CC'ing glasgow-haskell-users, as it got lost somehow. A message or two from me and Karel are also missing the list.) On Mon, Jan 14, 2013 at 1:27 PM, Ben Gamari bgamari.f...@gmail.com wrote: Austin Seipp mad@gmail.com writes: I've been working on ARM the past weekend. Here's where I'm at (semi-long email ahead.) I've also been working on this slowly over the last few weeks (in all of the discussion below, I'm building for a Pandaboard with Ubuntu's ghc 7.4 package). Unfortunately, most of my efforts have been going into convincing llc and gcc to build compatible objects. With GHC 7.6 simply taking the brute force approach with SRC_HC_OPTS seems to work, SRC_HC_OPTS= -H64m -Rghc-timing -optc-mfloat-abi=hard -optc-mcpu=cortex-a9 -optlc-mcpu=cortex-a9 # -optlc-float-abi=hard With this, I can produce a compiler and run the testsuite to generate this not-entirely-depressing picture, OVERALL SUMMARY for test run started at Sat Jan 5 17:12:12 UTC 2013 3400 total tests, which gave rise to 8322 test cases, of which 4 caused framework failures 5311 were skipped 2649 expected passes 47 had missing libraries 59 expected failures 0 unexpected passes 252 unexpected failures Sadly a good portion of the failures seem to be due to ghci crashing due to either a segmentation fault or illegal instruction. This is likely due to linker support needing either to be written or fixed. I'll have to brush off my linker knowledge and have a look at these (probably next weekend). Yes, the linker bit was one of the components of the stage2 compiler worrying me the most, especially since in our past conversations, we've both seen it segfault when linking libraries while building things like vector. I really can't wait for a future where GHC on Linux supports dynamic by default out of the box (and ARM should fit in this category, too.) In my opinion it's worth having a released compiler built as a refernce. The ghc-7.6 branch is pretty easy to get going if you ever have some spare CPU cycles available. Spare cycles do occur sometimes, so I'll give a shot to building it with LLVM-3.0 later when I get the chance. Overall I think squashing as many bugs as possible in HEAD is the correct route at the moment. This is only my opinion. My plans are to get a working stage1 registered GHC HEAD, and begin running the testsuite against it, filing down bugs. Eventually, this should lead to a stage2 as we narrow things down. Is this to say that you've been unable to successfully build a stage 2 compiler? I'm currently in the middle of a build of HEAD. We'll see how far this makes it. Yes, on my ODROID I have yet to build a stage2 compiler. This is mostly due to bugs in the LLVM backend in combination with the new code generator, it seems. I get through the entire stage1 build and the build of several of the libraries, but now I'm stuck compiling base with stage1. This is the bug I have yet to fix, in this area: http://hackage.haskell.org/trac/ghc/ticket/7575 I speculate the cause of this bug is eerily similar to the other two bugs I fixed relating to properly narrowing/widening LLVM variable types. Take a look at these bugs and their patches: http://hackage.haskell.org/trac/ghc/ticket/7571 http://hackage.haskell.org/trac/ghc/ticket/7580 so I imagine I can get this fixed tonight and move on. Out of curiosity, what are the build times on the ODROID? I haven't completed a full build so it's hard to estimate. But with a quick build and 'make -j4', the build seems to chug along fairly respectably, and I'd say I can get through the entire stage1 compiler build in the ballpark of ~30ish minutes. This is a very rough estimate because with enough parallelism, it's hard to see how far you are in the build, obviously. At a guess, I speculate a full build of everything at -j4 would be somewhere on the order of an hour and a half, to two-plus hours. I agree that having nightly buildbots would be very nice. I meant to setup my PandaBoard in this capacity after finishing my linker work, but sadly life and hardware failures got in the way. Yes, PandaBoards aren't the most reliable as several of us seem to realize. :) Anything you could contribute here would be wonderful. I'm new to the buildbot infrastructure, so when the time is right I'll rally people about this again. Very true. It would be very nice if we could handle this issue automatically after we figure out the proper way to handle it manually. I think Karel is right that we may be able to get 90% of the way there with a short hack in DriverPipeline, with some ./configure logic to fix it, but easier said than done, I'm sure (abusrdly long build times don't help I bet.) To be fair, hacking on the compiler itself is a bit sexier than hacking on the build system. There are also considerably fewer variables named things like '$'
Re: any successfull ghc registerised builds on arm?
On 01/14/13 08:49 PM, Austin Seipp wrote: Very true. It would be very nice if we could handle this issue automatically after we figure out the proper way to handle it manually. I think Karel is right that we may be able to get 90% of the way there with a short hack in DriverPipeline, with some ./configure logic to fix it, but easier said than done, I'm sure (abusrdly long build times don't help I bet.) What I'm talking about is aclocal.m4 GET_ARM_ISA function. There we need to check for ARMv6's VFP implementation and set ARM_ISA_EXT accordingly. I don't have Rasberry here so I'm not sure how to check for VFP versus VFPv2 in a best way, but probably we may omit this and just assume when we do have ARMv6 the VFP is v2? Once this is done, then just DriverPipeline.hs need to check for this and set appropriate vfpv2 option for llc... Karel ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
