Re: any successfull ghc registerised builds on arm?

[Karel Gardas]

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?

[Simon Marlow]

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.



?


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?

[Nathan Hüsken]

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?

[Stephen Paul Weber]

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  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?

[David Terei]

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:
 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?

[Nathan Hüsken]

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?

[Stephen Paul Weber]

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  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?

[Stephen Paul Weber]

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  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?

[Nathan Hüsken]

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?

[Karel Gardas]

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:

... 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) 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?

[Stephen Paul Weber]

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  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?

[Stephen Paul Weber]

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: 
 
... so not sure why I'm getting it and no one else is.


--
Stephen Paul Weber, @singpolyma
See  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?

[Karel Gardas]

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':
/tm

Re: any successfull ghc registerised builds on arm?

[Stephen Paul Weber]

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  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?

[Nathan Hüsken]

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?

[Nathan Hüsken]

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.
 


 ?
>>>
>>> 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?

[Nathan Hüsken]

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.
>>> 
>>>
>>> ?
>>
>> 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?

[Stephen Paul Weber]

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.


?


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-ar

Re: any successfull ghc registerised builds on arm?

[Karel Gardas]

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.



?


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?

[Stephen Paul Weber]

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.


?


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  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?

[Nathan Hüsken]

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
> 
> ?

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?

[Stephen Paul Weber]

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 
 
?



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  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?

[Nathan Hüsken]

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


___
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?

[Stephen Paul Weber]

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  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?

[Nathan Hüsken]

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?

[Simon Marlow]

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?

[Karel Gardas]

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?

[Stephen Paul Weber]

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  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?

[Karel Gardas]

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?

[Karel Gardas]

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?

[Stephen Paul Weber]

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  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?

[Ben Gamari]

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

___
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?

[Nathan Hüsken]

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?

[Stephen Paul Weber]

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  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?

[Stephen Paul Weber]

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  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?

[Stephen Paul Weber]

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  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?

[Karel Gardas]

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

Re: any successfull ghc registerised builds on arm?

[Austin Seipp]

(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  wrote:
> Austin Seipp  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 n

Re: any successfull ghc registerised builds on arm?

[Karel Gardas]

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?

[Stefan Kersten]

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


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