hrmmm, i seem to recall it being said that you need to use the GOLD linker on ARM. (i think some of this is detailed in http://bgamari.github.io/posts/2014-03-06-compiling-ghc-7.8-on-arm.html ) ,("ld command","arm-poky-linux-gnueabi-ld") is that GOLD? On Tue, Jul 8, 2014 at 1:51 AM, Michael Jones wrote:

I am pasting both the info from the HOST and TARGET compilers:

HOST ====

[("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","ArchX86_64") ,("target word size","8") ,("target has GNU nonexec stack","True") ,("target has .ident directive","True") ,("target has subsections via symbols","False") ,("LLVM llc command","llc") ,("LLVM opt command","opt") ,("Project version","7.6.3") ,("Booter version","7.6.3") ,("Stage","2") ,("Build platform","x86_64-unknown-linux") ,("Host platform","x86_64-unknown-linux") ,("Target platform","x86_64-unknown-linux") ,("Have interpreter","YES") ,("Object splitting supported","YES") ,("Have native code generator","YES") ,("Support SMP","YES") ,("Unregisterised","NO") ,("Tables next to code","YES") ,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn thr_debug_dyn thr_debug_p") ,("Leading underscore","NO") ,("Debug on","False") ,("LibDir","/usr/lib/ghc") ,("Global Package DB","/usr/lib/ghc/package.conf.d") ,("Gcc Linker flags","[\"-Wl,--hash-size=31\",\"-Wl,--reduce-memory-overheads\"]") ,("Ld Linker flags","[\"--hash-size=31\",\"--reduce-memory-overheads\"]") ]

TARGET =======

[("Project name","The Glorious Glasgow Haskell Compilation System") ,("GCC extra via C opts"," -fwrapv") ,("C compiler command","arm-poky-linux-gnueabi-gcc") ,("C compiler flags"," -fno-stack-protector") ,("C compiler link flags","") ,("ld command","arm-poky-linux-gnueabi-ld") ,("ld flags","") ,("ld supports compact unwind","YES") ,("ld supports build-id","YES") ,("ld supports filelist","NO") ,("ld is GNU ld","YES") ,("ar command","/usr/bin/ar") ,("ar flags","q") ,("ar supports at file","YES") ,("touch command","touch") ,("dllwrap command","/bin/false") ,("windres command","/bin/false") ,("libtool command","libtool") ,("perl command","/usr/bin/perl") ,("target os","OSLinux") ,("target arch","ArchARM {armISA = ARMv5, armISAExt = [], armABI = HARD}") ,("target word size","4") ,("target has GNU nonexec stack","False") ,("target has .ident directive","True") ,("target has subsections via symbols","False") ,("Unregisterised","NO") ,("LLVM llc command","llc") ,("LLVM opt command","opt") ,("Project version","7.8.2") ,("Booter version","7.6.3") ,("Stage","1") ,("Build platform","x86_64-unknown-linux") ,("Host platform","x86_64-unknown-linux") ,("Target platform","arm-unknown-linux") ,("Have interpreter","YES") ,("Object splitting supported","NO") ,("Have native code generator","NO") ,("Support SMP","YES") ,("Tables next to code","YES") ,("RTS ways","l debug thr thr_debug thr_l ") ,("Support dynamic-too","YES") ,("Support parallel --make","YES") ,("Dynamic by default","NO") ,("GHC Dynamic","NO") ,("Leading underscore","NO") ,("Debug on","False") ,("LibDir","/usr/local/lib/arm-unknown-linux-gnueabi-ghc-7.8.2") ,("Global Package DB","/usr/local/lib/arm-unknown-linux-gnueabi-ghc-7.8.2/package.conf.d") ]

On Jul 7, 2014, at 10:42 PM, Carter Schonwald wrote:

could you share the output of ghc --info?

On Tue, Jul 8, 2014 at 12:10 AM, Michael Jones wrote:

...

I am having problems building a GHC cross compiler for Linux (Yocto on a Wandboard) running on a Cortex A9, and need some advice on how to debug it.

The cross compiler produces an executable that runs on the Target, but fails to print. So I need help coming up with a strategy to narrow down the root cause.

Some details:

The application:

main = do putStrLn "Haskell start"

The command line options work. The program runs, and I can step through assembly. Debug data is printed to the console. But putStrLn fails, and program enters an infinite loop.

I compile my app as follows:

arm-unknown-linux-gnueabi-ghc -debug -static Main.hs

Using -threaded does not fix the problem.

Let me compare debug data from a run on my HOST, with a run on my TARGET. First, a run from my HOST:

created capset 0 of type 2 created capset 1 of type 3 cap 0: initialised assigned cap 0 to capset 0 assigned cap 0 to capset 1 cap 0: created thread 1 cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (suspended while making a foreign call) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (finished) cap 0: created thread 2 cap 0: running thread 2 (ThreadRunGHC) cap 0: thread 2 stopped (finished) cap 0: starting GC cap 0: GC working cap 0: GC idle cap 0: GC done cap 0: GC idle cap 0: GC done cap 0: GC idle cap 0: GC done cap 0: GC idle cap 0: GC done cap 0: all caps stopped for GC cap 0: finished GC removed cap 0 from capset 0 removed cap 0 from capset 1 cap 0: shutting down deleted capset 0 deleted capset 1

And, it prints properly. So this is my referenced for what it should do on the TARGET.

When I run on my TARGET, I get:

created capset 0 of type 2 created capset 1 of type 3 cap 0: initialised assigned cap 0 to capset 0 assigned cap 0 to capset 1 cap 0: created thread 1 cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (yielding) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (yielding) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (yielding) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (yielding) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (yielding) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (yielding) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (stack overflow) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (stack overflow) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (stack overflow) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (yielding) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (stack overflow) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (stack overflow) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (stack overflow) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (yielding) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (stack overflow) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (heap overflow) cap 0: starting GC cap 0: GC working cap 0: GC idle cap 0: GC done cap 0: GC idle cap 0: GC done cap 0: GC idle cap 0: GC done cap 0: all caps stopped for GC cap 0: finished GC cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (yielding) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (stack overflow) ...

And the debug data goes on forever, just as debugging assembly demonstrated an infinite loop.

Clearly, the following does not occur:

cap 0: thread 1 stopped (suspended while making a foreign call)

And there are overflows.

If I had to guess, it is possible that some code is in a loop retrying to foreign call, and failing. Certainly, it is in some kind of a loop, because I found a place I can put a break point and and telling GDB to continue will cause the break over and over at the same place. So somewhere there is a loop.

I can step through the application with GDB and see names of files and offsets in assembly. But without a true source code debug, that is a bit rough, especially for someone that does not know the RTS code. If there was a way to compile such that C source code was available and a place to break, that would help. However, I suspect since it never makes a foreign call, there is no place in C to place the breakpoint anyway. So I am also assuming there is no direct way to debug with GDB.

But, I can see debug output printed to the console. My hope is there is a way to enable more printing, or a place I can add more print functions to help find the problem.

So I think I need one of the following:

- A solution from someone that has seen this before, perhaps on the iPhone - How to enable more debug logging - Where in the source code to add debug statements to narrow down the problem

Thanks for any help you can give.

Mike

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

I'm not sure if this is already solved, but if you cross-compile to A9, why do you use ARMv5 platform OS? ("target arch","ArchARM {armISA = ARMv5, armISAExt = [], armABI = HARD}") this looks really strange. armABI HARD, that means FP data in FP regs, still no VFP in armISAExt and even armISA set to ARMv5. For example on my ubuntu 12.04 I do have: ("target arch", "ArchARM {armISA = ARMv7, armISAExt = [VFPv3,NEON], armABI = HARD}"), which is right for pandaboard which is dual Cortex-A9. So, shortly I really do not know if you do not hit some corner case in LLVM here. I would certainly suggest especially considering your Cortex-A9 target to update your OS to get to what I do have here: ARMv7+VFPv3/NEON+ABI HARD. BTW: Another issue may be that GHC misconfigures on your platform and they you will need to tell us more about your target OS... Cheers, Karel On 07/ 8/14 07:51 AM, Michael Jones wrote:

I am pasting both the info from the HOST and TARGET compilers:

HOST ====

[("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","ArchX86_64") ,("target word size","8") ,("target has GNU nonexec stack","True") ,("target has .ident directive","True") ,("target has subsections via symbols","False") ,("LLVM llc command","llc") ,("LLVM opt command","opt") ,("Project version","7.6.3") ,("Booter version","7.6.3") ,("Stage","2") ,("Build platform","x86_64-unknown-linux") ,("Host platform","x86_64-unknown-linux") ,("Target platform","x86_64-unknown-linux") ,("Have interpreter","YES") ,("Object splitting supported","YES") ,("Have native code generator","YES") ,("Support SMP","YES") ,("Unregisterised","NO") ,("Tables next to code","YES") ,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn thr_debug_dyn thr_debug_p") ,("Leading underscore","NO") ,("Debug on","False") ,("LibDir","/usr/lib/ghc") ,("Global Package DB","/usr/lib/ghc/package.conf.d") ,("Gcc Linker flags","[\"-Wl,--hash-size=31\",\"-Wl,--reduce-memory-overheads\"]") ,("Ld Linker flags","[\"--hash-size=31\",\"--reduce-memory-overheads\"]") ]

TARGET =======

[("Project name","The Glorious Glasgow Haskell Compilation System") ,("GCC extra via C opts"," -fwrapv") ,("C compiler command","arm-poky-linux-gnueabi-gcc") ,("C compiler flags"," -fno-stack-protector") ,("C compiler link flags","") ,("ld command","arm-poky-linux-gnueabi-ld") ,("ld flags","") ,("ld supports compact unwind","YES") ,("ld supports build-id","YES") ,("ld supports filelist","NO") ,("ld is GNU ld","YES") ,("ar command","/usr/bin/ar") ,("ar flags","q") ,("ar supports at file","YES") ,("touch command","touch") ,("dllwrap command","/bin/false") ,("windres command","/bin/false") ,("libtool command","libtool") ,("perl command","/usr/bin/perl") ,("target os","OSLinux") ,("target arch","ArchARM {armISA = ARMv5, armISAExt = [], armABI = HARD}") ,("target word size","4") ,("target has GNU nonexec stack","False") ,("target has .ident directive","True") ,("target has subsections via symbols","False") ,("Unregisterised","NO") ,("LLVM llc command","llc") ,("LLVM opt command","opt") ,("Project version","7.8.2") ,("Booter version","7.6.3") ,("Stage","1") ,("Build platform","x86_64-unknown-linux") ,("Host platform","x86_64-unknown-linux") ,("Target platform","arm-unknown-linux") ,("Have interpreter","YES") ,("Object splitting supported","NO") ,("Have native code generator","NO") ,("Support SMP","YES") ,("Tables next to code","YES") ,("RTS ways","l debug thr thr_debug thr_l ") ,("Support dynamic-too","YES") ,("Support parallel --make","YES") ,("Dynamic by default","NO") ,("GHC Dynamic","NO") ,("Leading underscore","NO") ,("Debug on","False") ,("LibDir","/usr/local/lib/arm-unknown-linux-gnueabi-ghc-7.8.2") ,("Global Package DB","/usr/local/lib/arm-unknown-linux-gnueabi-ghc-7.8.2/package.conf.d") ]

On Jul 7, 2014, at 10:42 PM, Carter Schonwald mailto:carter.schonwald@gmail.com> wrote:

...

could you share the output of ghc --info?

On Tue, Jul 8, 2014 at 12:10 AM, Michael Jones mailto:mike@proclivis.com> wrote:

I am having problems building a GHC cross compiler for Linux (Yocto on a Wandboard) running on a Cortex A9, and need some advice on how to debug it.

The cross compiler produces an executable that runs on the Target, but fails to print. So I need help coming up with a strategy to narrow down the root cause.

Some details:

The application:

main = do putStrLn "Haskell start"

The command line options work. The program runs, and I can step through assembly. Debug data is printed to the console. But putStrLn fails, and program enters an infinite loop.

I compile my app as follows:

arm-unknown-linux-gnueabi-ghc -debug -static Main.hs

Using -threaded does not fix the problem.

Let me compare debug data from a run on my HOST, with a run on my TARGET. First, a run from my HOST:

created capset 0 of type 2 created capset 1 of type 3 cap 0: initialised assigned cap 0 to capset 0 assigned cap 0 to capset 1 cap 0: created thread 1 cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (suspended while making a foreign call) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (finished) cap 0: created thread 2 cap 0: running thread 2 (ThreadRunGHC) cap 0: thread 2 stopped (finished) cap 0: starting GC cap 0: GC working cap 0: GC idle cap 0: GC done cap 0: GC idle cap 0: GC done cap 0: GC idle cap 0: GC done cap 0: GC idle cap 0: GC done cap 0: all caps stopped for GC cap 0: finished GC removed cap 0 from capset 0 removed cap 0 from capset 1 cap 0: shutting down deleted capset 0 deleted capset 1

And, it prints properly. So this is my referenced for what it should do on the TARGET.

When I run on my TARGET, I get:

created capset 0 of type 2 created capset 1 of type 3 cap 0: initialised assigned cap 0 to capset 0 assigned cap 0 to capset 1 cap 0: created thread 1 cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (yielding) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (yielding) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (yielding) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (yielding) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (yielding) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (yielding) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (stack overflow) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (stack overflow) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (stack overflow) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (yielding) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (stack overflow) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (stack overflow) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (stack overflow) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (yielding) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (stack overflow) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (heap overflow) cap 0: starting GC cap 0: GC working cap 0: GC idle cap 0: GC done cap 0: GC idle cap 0: GC done cap 0: GC idle cap 0: GC done cap 0: all caps stopped for GC cap 0: finished GC cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (yielding) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (stack overflow) ...

And the debug data goes on forever, just as debugging assembly demonstrated an infinite loop.

Clearly, the following does not occur:

cap 0: thread 1 stopped (suspended while making a foreign call)

And there are overflows.

If I had to guess, it is possible that some code is in a loop retrying to foreign call, and failing. Certainly, it is in some kind of a loop, because I found a place I can put a break point and and telling GDB to continue will cause the break over and over at the same place. So somewhere there is a loop.

I can step through the application with GDB and see names of files and offsets in assembly. But without a true source code debug, that is a bit rough, especially for someone that does not know the RTS code. If there was a way to compile such that C source code was available and a place to break, that would help. However, I suspect since it never makes a foreign call, there is no place in C to place the breakpoint anyway. So I am also assuming there is no direct way to debug with GDB.

But, I can see debug output printed to the console. My hope is there is a way to enable more printing, or a place I can add more print functions to help find the problem.

So I think I need one of the following:

- A solution from someone that has seen this before, perhaps on the iPhone - How to enable more debug logging - Where in the source code to add debug statements to narrow down the problem

Thanks for any help you can give.

Mike

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org mailto: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

Karel, I have failed to figure out how to make this happen: ("target arch", "ArchARM {armISA = ARMv7, armISAExt = [VFPv3,NEON], armABI = HARD}”) I have added poky to the list of vendors in aclocal.m4 then configured like this: /configure --target=arm-poky-linux-gnueabi --with-gcc=arm-poky-linux-gnueabi-gcc But I end up with ARMv5. I am new to Autotools and the Haskell build system, so I am not sure what controls this. I assume the idea is that the gcc cross-compiler compiles some code that checks for versions when it evaluates stuff like: AC_COMPILE_IFELSE([ AC_LANG_PROGRAM( [], [#if defined(__ARM_ARCH_2__) || \ defined(__ARM_ARCH_3__) || \ defined(__ARM_ARCH_3M__) || \ defined(__ARM_ARCH_4__) || \ defined(__ARM_ARCH_4T__) || \ So I then suspect the compiler needs options like -mcpu=cortex-a9 -mfpu=neon to make the proper version defined, so that the code can check the architecture. But if all these assumptions are true, it is not clear where to put these options. But that is a big if. Can you explain or point to a doc that explains how this works? The Haskell Developer Wiki does not get into the details at this level. Or, if you have tweaked files for the Panda, I can difference them with mine and figure it out. Thanks, Mike On Jul 11, 2014, at 4:35 AM, Karel Gardas wrote:

I'm not sure if this is already solved, but if you cross-compile to A9, why do you use ARMv5 platform OS?

("target arch","ArchARM {armISA = ARMv5, armISAExt = [], armABI = HARD}")

this looks really strange. armABI HARD, that means FP data in FP regs, still no VFP in armISAExt and even armISA set to ARMv5.

For example on my ubuntu 12.04 I do have:

("target arch", "ArchARM {armISA = ARMv7, armISAExt = [VFPv3,NEON], armABI = HARD}"),

which is right for pandaboard which is dual Cortex-A9.

So, shortly I really do not know if you do not hit some corner case in LLVM here. I would certainly suggest especially considering your Cortex-A9 target to update your OS to get to what I do have here: ARMv7+VFPv3/NEON+ABI HARD.

BTW: Another issue may be that GHC misconfigures on your platform and they you will need to tell us more about your target OS...

Cheers, Karel

On 07/ 8/14 07:51 AM, Michael Jones wrote:

...

I am pasting both the info from the HOST and TARGET compilers:

HOST ====

[("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","ArchX86_64") ,("target word size","8") ,("target has GNU nonexec stack","True") ,("target has .ident directive","True") ,("target has subsections via symbols","False") ,("LLVM llc command","llc") ,("LLVM opt command","opt") ,("Project version","7.6.3") ,("Booter version","7.6.3") ,("Stage","2") ,("Build platform","x86_64-unknown-linux") ,("Host platform","x86_64-unknown-linux") ,("Target platform","x86_64-unknown-linux") ,("Have interpreter","YES") ,("Object splitting supported","YES") ,("Have native code generator","YES") ,("Support SMP","YES") ,("Unregisterised","NO") ,("Tables next to code","YES") ,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn thr_debug_dyn thr_debug_p") ,("Leading underscore","NO") ,("Debug on","False") ,("LibDir","/usr/lib/ghc") ,("Global Package DB","/usr/lib/ghc/package.conf.d") ,("Gcc Linker flags","[\"-Wl,--hash-size=31\",\"-Wl,--reduce-memory-overheads\"]") ,("Ld Linker flags","[\"--hash-size=31\",\"--reduce-memory-overheads\"]") ]

TARGET =======

[("Project name","The Glorious Glasgow Haskell Compilation System") ,("GCC extra via C opts"," -fwrapv") ,("C compiler command","arm-poky-linux-gnueabi-gcc") ,("C compiler flags"," -fno-stack-protector") ,("C compiler link flags","") ,("ld command","arm-poky-linux-gnueabi-ld") ,("ld flags","") ,("ld supports compact unwind","YES") ,("ld supports build-id","YES") ,("ld supports filelist","NO") ,("ld is GNU ld","YES") ,("ar command","/usr/bin/ar") ,("ar flags","q") ,("ar supports at file","YES") ,("touch command","touch") ,("dllwrap command","/bin/false") ,("windres command","/bin/false") ,("libtool command","libtool") ,("perl command","/usr/bin/perl") ,("target os","OSLinux") ,("target arch","ArchARM {armISA = ARMv5, armISAExt = [], armABI = HARD}") ,("target word size","4") ,("target has GNU nonexec stack","False") ,("target has .ident directive","True") ,("target has subsections via symbols","False") ,("Unregisterised","NO") ,("LLVM llc command","llc") ,("LLVM opt command","opt") ,("Project version","7.8.2") ,("Booter version","7.6.3") ,("Stage","1") ,("Build platform","x86_64-unknown-linux") ,("Host platform","x86_64-unknown-linux") ,("Target platform","arm-unknown-linux") ,("Have interpreter","YES") ,("Object splitting supported","NO") ,("Have native code generator","NO") ,("Support SMP","YES") ,("Tables next to code","YES") ,("RTS ways","l debug thr thr_debug thr_l ") ,("Support dynamic-too","YES") ,("Support parallel --make","YES") ,("Dynamic by default","NO") ,("GHC Dynamic","NO") ,("Leading underscore","NO") ,("Debug on","False") ,("LibDir","/usr/local/lib/arm-unknown-linux-gnueabi-ghc-7.8.2") ,("Global Package DB","/usr/local/lib/arm-unknown-linux-gnueabi-ghc-7.8.2/package.conf.d") ]

On Jul 7, 2014, at 10:42 PM, Carter Schonwald mailto:carter.schonwald@gmail.com> wrote:

...

could you share the output of ghc --info?

On Tue, Jul 8, 2014 at 12:10 AM, Michael Jones mailto:mike@proclivis.com> wrote:

I am having problems building a GHC cross compiler for Linux (Yocto on a Wandboard) running on a Cortex A9, and need some advice on how to debug it.

The cross compiler produces an executable that runs on the Target, but fails to print. So I need help coming up with a strategy to narrow down the root cause.

Some details:

The application:

main = do putStrLn "Haskell start"

The command line options work. The program runs, and I can step through assembly. Debug data is printed to the console. But putStrLn fails, and program enters an infinite loop.

I compile my app as follows:

arm-unknown-linux-gnueabi-ghc -debug -static Main.hs

Using -threaded does not fix the problem.

Let me compare debug data from a run on my HOST, with a run on my TARGET. First, a run from my HOST:

created capset 0 of type 2 created capset 1 of type 3 cap 0: initialised assigned cap 0 to capset 0 assigned cap 0 to capset 1 cap 0: created thread 1 cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (suspended while making a foreign call) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (finished) cap 0: created thread 2 cap 0: running thread 2 (ThreadRunGHC) cap 0: thread 2 stopped (finished) cap 0: starting GC cap 0: GC working cap 0: GC idle cap 0: GC done cap 0: GC idle cap 0: GC done cap 0: GC idle cap 0: GC done cap 0: GC idle cap 0: GC done cap 0: all caps stopped for GC cap 0: finished GC removed cap 0 from capset 0 removed cap 0 from capset 1 cap 0: shutting down deleted capset 0 deleted capset 1

And, it prints properly. So this is my referenced for what it should do on the TARGET.

When I run on my TARGET, I get:

created capset 0 of type 2 created capset 1 of type 3 cap 0: initialised assigned cap 0 to capset 0 assigned cap 0 to capset 1 cap 0: created thread 1 cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (yielding) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (yielding) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (yielding) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (yielding) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (yielding) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (yielding) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (stack overflow) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (stack overflow) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (stack overflow) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (yielding) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (stack overflow) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (stack overflow) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (stack overflow) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (yielding) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (stack overflow) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (heap overflow) cap 0: starting GC cap 0: GC working cap 0: GC idle cap 0: GC done cap 0: GC idle cap 0: GC done cap 0: GC idle cap 0: GC done cap 0: all caps stopped for GC cap 0: finished GC cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (yielding) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (stack overflow) ...

And the debug data goes on forever, just as debugging assembly demonstrated an infinite loop.

Clearly, the following does not occur:

cap 0: thread 1 stopped (suspended while making a foreign call)

And there are overflows.

If I had to guess, it is possible that some code is in a loop retrying to foreign call, and failing. Certainly, it is in some kind of a loop, because I found a place I can put a break point and and telling GDB to continue will cause the break over and over at the same place. So somewhere there is a loop.

I can step through the application with GDB and see names of files and offsets in assembly. But without a true source code debug, that is a bit rough, especially for someone that does not know the RTS code. If there was a way to compile such that C source code was available and a place to break, that would help. However, I suspect since it never makes a foreign call, there is no place in C to place the breakpoint anyway. So I am also assuming there is no direct way to debug with GDB.

But, I can see debug output printed to the console. My hope is there is a way to enable more printing, or a place I can add more print functions to help find the problem.

So I think I need one of the following:

- A solution from someone that has seen this before, perhaps on the iPhone - How to enable more debug logging - Where in the source code to add debug statements to narrow down the problem

Thanks for any help you can give.

Mike

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org mailto: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

Karel, Thanks. This helps. If I understand, you have Linux running on a Panda, and on that Panda system you have gcc, and you compile GHC on the Panda itself, rather than build a cross compiler. I can see the advantage of building this way. As far as cross compilers, I have a reason for trying to build a cross compiler, other than the ability to keep the image of the target small. That is, eventually, I want to be able to compile for an RTOS and/or bare iron system. I decided that learning to cross compile for Linux first would be a good approach. Learn the build system on something known to work. So I probably will not give up on that. I got a book on Autoconfig. I’ll just have to dig a level deeper into the whole build system. Mainly it means learning the M4 system. I have never used it. Below are the defines from the command you suggested. Thanks for that, got me over an ignorance hump. At least this define, __ARM_ARCH_5T__, is in the aclocal.m4 file. So I will have to study the macros until I figure out what controls the gcc options passed to the gcc cross compiler. I guess my question is what actually controls this result ("target arch", "ArchARM {armISA = ARMv7, armISAExt = [VFPv3,NEON], armABI = HARD}”)? Are these controlled by the defines below, or are they controlled by passing gcc arguments to the gcc compiler when the Haskell compiler calls gcc? Mike #define __ARM_SIZEOF_WCHAR_T 32 #define __ARM_ARCH_ISA_ARM 1 #define __ARM_FP 12 #define __ARM_NEON_FP 4 #define __ARM_SIZEOF_MINIMAL_ENUM 4 #define __ARM_PCS_VFP 1 #define __ARM_ARCH_5T__ 1 #define __ARM_FEATURE_CLZ 1 #define __ARM_ARCH_ISA_THUMB 1 #define __ARM_ARCH 5 #define __arm__ 1 #define __ARM_EABI__ 1 mike@ubuntu:~/fsl-community-bsp/build/tmp/sysroots/x86_64-linux/usr/bin/cortexa9hf-vfp-neon-poky-linux-gnueabi$ ./arm-poky-linux-gnueabi-gcc -v Using built-in specs. COLLECT_GCC=./arm-poky-linux-gnueabi-gcc COLLECT_LTO_WRAPPER=/home/mike/fsl-community-bsp/build/tmp/sysroots/x86_64-linux/usr/libexec/cortexa9hf-vfp-neon-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.8.2/lto-wrapper Target: arm-poky-linux-gnueabi Configured with: /home/mike/fsl-community-bsp/build/tmp/work-shared/gcc-4.8.2-r0/gcc-4.8.2/configure --build=x86_64-linux --host=x86_64-linux --target=arm-poky-linux-gnueabi --prefix=/home/mike/fsl-community-bsp/build/tmp/sysroots/x86_64-linux/usr --exec_prefix=/home/mike/fsl-community-bsp/build/tmp/sysroots/x86_64-linux/usr --bindir=/home/mike/fsl-community-bsp/build/tmp/sysroots/x86_64-linux/usr/bin/cortexa9hf-vfp-neon-poky-linux-gnueabi --sbindir=/home/mike/fsl-community-bsp/build/tmp/sysroots/x86_64-linux/usr/bin/cortexa9hf-vfp-neon-poky-linux-gnueabi --libexecdir=/home/mike/fsl-community-bsp/build/tmp/sysroots/x86_64-linux/usr/libexec/cortexa9hf-vfp-neon-poky-linux-gnueabi --datadir=/home/mike/fsl-community-bsp/build/tmp/sysroots/x86_64-linux/usr/share --sysconfdir=/home/mike/fsl-community-bsp/build/tmp/sysroots/x86_64-linux/etc --sharedstatedir=/home/mike/fsl-community-bsp/build/tmp/sysroots/x86_64-linux/com --localstatedir=/home/mike/fsl-community-bsp/build/tmp/sysroots/x86_64-linux/var --libdir=/home/mike/fsl-community-bsp/build/tmp/sysroots/x86_64-linux/usr/lib/cortexa9hf-vfp-neon-poky-linux-gnueabi --includedir=/home/mike/fsl-community-bsp/build/tmp/sysroots/x86_64-linux/usr/include --oldincludedir=/home/mike/fsl-community-bsp/build/tmp/sysroots/x86_64-linux/usr/include --infodir=/home/mike/fsl-community-bsp/build/tmp/sysroots/x86_64-linux/usr/share/info --mandir=/home/mike/fsl-community-bsp/build/tmp/sysroots/x86_64-linux/usr/share/man --disable-silent-rules --disable-dependency-tracking --with-libtool-sysroot=/home/mike/fsl-community-bsp/build/tmp/sysroots/x86_64-linux --enable-clocale=generic --with-gnu-ld --enable-shared --enable-languages=c,c++ --enable-threads=posix --disable-multilib --enable-c99 --enable-long-long --enable-symvers=gnu --enable-libstdcxx-pch --program-prefix=arm-poky-linux-gnueabi- --without-local-prefix --enable-target-optspace --enable-lto --enable-libssp --disable-bootstrap --disable-libmudflap --with-system-zlib --with-linker-hash-style=gnu --enable-linker-build-id --with-ppl=no --with-cloog=no --enable-checking=release --enable-cheaders=c_global --with-float=hard --with-gxx-include-dir=/home/mike/fsl-community-bsp/build/tmp/sysroots/wandboard-quad/usr/include/c++ --with-sysroot=/home/mike/fsl-community-bsp/build/tmp/sysroots/wandboard-quad --with-build-sysroot=/home/mike/fsl-community-bsp/build/tmp/sysroots/wandboard-quad --enable-poison-system-directories --disable-libunwind-exceptions --with-mpfr=/home/mike/fsl-community-bsp/build/tmp/sysroots/x86_64-linux/usr --with-system-zlib --disable-nls Thread model: posix gcc version 4.8.2 (GCC) mike@ubuntu:~/fsl-community-bsp/build/tmp/sysroots/x86_64-linux/usr/bin/cortexa9hf-vfp-neon-poky-linux-gnueabi$ #define __DBL_MIN_EXP__ (-1021) #define __HQ_FBIT__ 15 #define __UINT_LEAST16_MAX__ 65535 #define __ARM_SIZEOF_WCHAR_T 32 #define __ATOMIC_ACQUIRE 2 #define __SFRACT_IBIT__ 0 #define __FLT_MIN__ 1.1754943508222875e-38F #define __UFRACT_MAX__ 0XFFFFP-16UR #define __UINT_LEAST8_TYPE__ unsigned char #define __DQ_FBIT__ 63 #define __INTMAX_C(c) c ## LL #define __ULFRACT_FBIT__ 32 #define __SACCUM_EPSILON__ 0x1P-7HK #define __CHAR_BIT__ 8 #define __USQ_IBIT__ 0 #define __UINT8_MAX__ 255 #define __ACCUM_FBIT__ 15 #define __WINT_MAX__ 4294967295U #define __USFRACT_FBIT__ 8 #define __ORDER_LITTLE_ENDIAN__ 1234 #define __SIZE_MAX__ 4294967295U #define __ARM_ARCH_ISA_ARM 1 #define __WCHAR_MAX__ 4294967295U #define __LACCUM_IBIT__ 32 #define __DBL_DENORM_MIN__ ((double)4.9406564584124654e-324L) #define __GCC_ATOMIC_CHAR_LOCK_FREE 1 #define __FLT_EVAL_METHOD__ 0 #define __unix__ 1 #define __LLACCUM_MAX__ 0X7FFFFFFFFFFFFFFFP-31LLK #define __GCC_ATOMIC_CHAR32_T_LOCK_FREE 1 #define __FRACT_FBIT__ 15 #define __UINT_FAST64_MAX__ 18446744073709551615ULL #define __SIG_ATOMIC_TYPE__ int #define __UACCUM_FBIT__ 16 #define __DBL_MIN_10_EXP__ (-307) #define __FINITE_MATH_ONLY__ 0 #define __ARMEL__ 1 #define __LFRACT_IBIT__ 0 #define __GNUC_PATCHLEVEL__ 2 #define __LFRACT_MAX__ 0X7FFFFFFFP-31LR #define __UINT_FAST8_MAX__ 255 #define __DEC64_MAX_EXP__ 385 #define __INT8_C(c) c #define __UINT_LEAST64_MAX__ 18446744073709551615ULL #define __SA_FBIT__ 15 #define __SHRT_MAX__ 32767 #define __LDBL_MAX__ 1.7976931348623157e+308L #define __FRACT_MAX__ 0X7FFFP-15R #define __UFRACT_FBIT__ 16 #define __ARM_FP 12 #define __UFRACT_MIN__ 0.0UR #define __UINT_LEAST8_MAX__ 255 #define __GCC_ATOMIC_BOOL_LOCK_FREE 1 #define __UINTMAX_TYPE__ long long unsigned int #define __LLFRACT_EPSILON__ 0x1P-63LLR #define __linux 1 #define __DEC32_EPSILON__ 1E-6DF #define __CHAR_UNSIGNED__ 1 #define __UINT32_MAX__ 4294967295U #define __ULFRACT_MAX__ 0XFFFFFFFFP-32ULR #define __TA_IBIT__ 64 #define __LDBL_MAX_EXP__ 1024 #define __WINT_MIN__ 0U #define __linux__ 1 #define __ULLFRACT_MIN__ 0.0ULLR #define __SCHAR_MAX__ 127 #define __WCHAR_MIN__ 0U #define __INT64_C(c) c ## LL #define __DBL_DIG__ 15 #define __ARM_NEON_FP 4 #define __GCC_ATOMIC_POINTER_LOCK_FREE 1 #define __LLACCUM_MIN__ (-0X1P31LLK-0X1P31LLK) #define __SIZEOF_INT__ 4 #define __SIZEOF_POINTER__ 4 #define __USACCUM_IBIT__ 8 #define __USER_LABEL_PREFIX__ #define __STDC_HOSTED__ 1 #define __LDBL_HAS_INFINITY__ 1 #define __LFRACT_MIN__ (-0.5LR-0.5LR) #define __HA_IBIT__ 8 #define __TQ_IBIT__ 0 #define __FLT_EPSILON__ 1.1920928955078125e-7F #define __APCS_32__ 1 #define __USFRACT_IBIT__ 0 #define __LDBL_MIN__ 2.2250738585072014e-308L #define __FRACT_MIN__ (-0.5R-0.5R) #define __DEC32_MAX__ 9.999999E96DF #define __DA_IBIT__ 32 #define __ARM_SIZEOF_MINIMAL_ENUM 4 #define __INT32_MAX__ 2147483647 #define __UQQ_FBIT__ 8 #define __SIZEOF_LONG__ 4 #define __UACCUM_MAX__ 0XFFFFFFFFP-16UK #define __STDC_IEC_559__ 1 #define __STDC_ISO_10646__ 201103L #define __UINT16_C(c) c #define __DECIMAL_DIG__ 17 #define __LFRACT_EPSILON__ 0x1P-31LR #define __ULFRACT_MIN__ 0.0ULR #define __gnu_linux__ 1 #define __ARM_PCS_VFP 1 #define __LDBL_HAS_QUIET_NAN__ 1 #define __ULACCUM_IBIT__ 32 #define __UACCUM_EPSILON__ 0x1P-16UK #define __GNUC__ 4 #define __ULLACCUM_MAX__ 0XFFFFFFFFFFFFFFFFP-32ULLK #define __HQ_IBIT__ 0 #define __FLT_HAS_DENORM__ 1 #define __SIZEOF_LONG_DOUBLE__ 8 #define __ARM_ARCH_5T__ 1 #define __BIGGEST_ALIGNMENT__ 8 #define __DQ_IBIT__ 0 #define __DBL_MAX__ ((double)1.7976931348623157e+308L) #define __ULFRACT_IBIT__ 0 #define __INT_FAST32_MAX__ 2147483647 #define __DBL_HAS_INFINITY__ 1 #define __ACCUM_IBIT__ 16 #define __DEC32_MIN_EXP__ (-94) #define __THUMB_INTERWORK__ 1 #define __LACCUM_MAX__ 0X7FFFFFFFFFFFFFFFP-31LK #define __INT_FAST16_TYPE__ int #define __LDBL_HAS_DENORM__ 1 #define __DEC128_MAX__ 9.999999999999999999999999999999999E6144DL #define __INT_LEAST32_MAX__ 2147483647 #define __DEC32_MIN__ 1E-95DF #define __ACCUM_MAX__ 0X7FFFFFFFP-15K #define __DBL_MAX_EXP__ 1024 #define __USACCUM_EPSILON__ 0x1P-8UHK #define __DEC128_EPSILON__ 1E-33DL #define __SFRACT_MAX__ 0X7FP-7HR #define __FRACT_IBIT__ 0 #define __PTRDIFF_MAX__ 2147483647 #define __UACCUM_MIN__ 0.0UK #define __STDC_NO_THREADS__ 1 #define __UACCUM_IBIT__ 16 #define __LONG_LONG_MAX__ 9223372036854775807LL #define __SIZEOF_SIZE_T__ 4 #define __ULACCUM_MAX__ 0XFFFFFFFFFFFFFFFFP-32ULK #define __SIZEOF_WINT_T__ 4 #define __SA_IBIT__ 16 #define __ULLACCUM_MIN__ 0.0ULLK #define __GXX_ABI_VERSION 1002 #define __UTA_FBIT__ 64 #define __FLT_MIN_EXP__ (-125) #define __USFRACT_MAX__ 0XFFP-8UHR #define __UFRACT_IBIT__ 0 #define __INT_FAST64_TYPE__ long long int #define __DBL_MIN__ ((double)2.2250738585072014e-308L) #define __LACCUM_MIN__ (-0X1P31LK-0X1P31LK) #define __ULLACCUM_FBIT__ 32 #define __GXX_TYPEINFO_EQUALITY_INLINE 0 #define __ULLFRACT_EPSILON__ 0x1P-64ULLR #define __DEC128_MIN__ 1E-6143DL #define __REGISTER_PREFIX__ #define __UINT16_MAX__ 65535 #define __DBL_HAS_DENORM__ 1 #define __ACCUM_MIN__ (-0X1P15K-0X1P15K) #define __SQ_IBIT__ 0 #define __UINT8_TYPE__ unsigned char #define __UHA_FBIT__ 8 #define __NO_INLINE__ 1 #define __SFRACT_MIN__ (-0.5HR-0.5HR) #define __UTQ_FBIT__ 128 #define __FLT_MANT_DIG__ 24 #define __VERSION__ "4.8.2" #define __UINT64_C(c) c ## ULL #define __ULLFRACT_FBIT__ 64 #define __FRACT_EPSILON__ 0x1P-15R #define __ULACCUM_MIN__ 0.0ULK #define _STDC_PREDEF_H 1 #define __UDA_FBIT__ 32 #define __LLACCUM_EPSILON__ 0x1P-31LLK #define __GCC_ATOMIC_INT_LOCK_FREE 1 #define __FLOAT_WORD_ORDER__ __ORDER_LITTLE_ENDIAN__ #define __USFRACT_MIN__ 0.0UHR #define __UQQ_IBIT__ 0 #define __STDC_IEC_559_COMPLEX__ 1 #define __INT32_C(c) c #define __DEC64_EPSILON__ 1E-15DD #define __ORDER_PDP_ENDIAN__ 3412 #define __DEC128_MIN_EXP__ (-6142) #define __UHQ_FBIT__ 16 #define __LLACCUM_FBIT__ 31 #define __INT_FAST32_TYPE__ int #define __UINT_LEAST16_TYPE__ short unsigned int #define unix 1 #define __INT16_MAX__ 32767 #define __SIZE_TYPE__ unsigned int #define __UINT64_MAX__ 18446744073709551615ULL #define __UDQ_FBIT__ 64 #define __INT8_TYPE__ signed char #define __ELF__ 1 #define __ULFRACT_EPSILON__ 0x1P-32ULR #define __LLFRACT_FBIT__ 63 #define __FLT_RADIX__ 2 #define __INT_LEAST16_TYPE__ short int #define __LDBL_EPSILON__ 2.2204460492503131e-16L #define __UINTMAX_C(c) c ## ULL #define __SACCUM_MAX__ 0X7FFFP-7HK #define __SIG_ATOMIC_MAX__ 2147483647 #define __GCC_ATOMIC_WCHAR_T_LOCK_FREE 1 #define __VFP_FP__ 1 #define __SIZEOF_PTRDIFF_T__ 4 #define __LACCUM_EPSILON__ 0x1P-31LK #define __DEC32_SUBNORMAL_MIN__ 0.000001E-95DF #define __INT_FAST16_MAX__ 2147483647 #define __UINT_FAST32_MAX__ 4294967295U #define __UINT_LEAST64_TYPE__ long long unsigned int #define __USACCUM_MAX__ 0XFFFFP-8UHK #define __SFRACT_EPSILON__ 0x1P-7HR #define __FLT_HAS_QUIET_NAN__ 1 #define __FLT_MAX_10_EXP__ 38 #define __LONG_MAX__ 2147483647L #define __DEC128_SUBNORMAL_MIN__ 0.000000000000000000000000000000001E-6143DL #define __FLT_HAS_INFINITY__ 1 #define __unix 1 #define __USA_FBIT__ 16 #define __UINT_FAST16_TYPE__ unsigned int #define __DEC64_MAX__ 9.999999999999999E384DD #define __CHAR16_TYPE__ short unsigned int #define __PRAGMA_REDEFINE_EXTNAME 1 #define __INT_LEAST16_MAX__ 32767 #define __DEC64_MANT_DIG__ 16 #define __INT64_MAX__ 9223372036854775807LL #define __UINT_LEAST32_MAX__ 4294967295U #define __SACCUM_FBIT__ 7 #define __GCC_ATOMIC_LONG_LOCK_FREE 1 #define __INT_LEAST64_TYPE__ long long int #define __ARM_FEATURE_CLZ 1 #define __INT16_TYPE__ short int #define __INT_LEAST8_TYPE__ signed char #define __SQ_FBIT__ 31 #define __DEC32_MAX_EXP__ 97 #define __ARM_ARCH_ISA_THUMB 1 #define __INT_FAST8_MAX__ 127 #define __ARM_ARCH 5 #define __INTPTR_MAX__ 2147483647 #define __QQ_FBIT__ 7 #define linux 1 #define __UTA_IBIT__ 64 #define __LDBL_MANT_DIG__ 53 #define __SFRACT_FBIT__ 7 #define __SACCUM_MIN__ (-0X1P7HK-0X1P7HK) #define __DBL_HAS_QUIET_NAN__ 1 #define __SIG_ATOMIC_MIN__ (-__SIG_ATOMIC_MAX__ - 1) #define __INTPTR_TYPE__ int #define __UINT16_TYPE__ short unsigned int #define __WCHAR_TYPE__ unsigned int #define __SIZEOF_FLOAT__ 4 #define __USQ_FBIT__ 32 #define __UINTPTR_MAX__ 4294967295U #define __DEC64_MIN_EXP__ (-382) #define __ULLACCUM_IBIT__ 32 #define __INT_FAST64_MAX__ 9223372036854775807LL #define __GCC_ATOMIC_TEST_AND_SET_TRUEVAL 1 #define __FLT_DIG__ 6 #define __UINT_FAST64_TYPE__ long long unsigned int #define __INT_MAX__ 2147483647 #define __LACCUM_FBIT__ 31 #define __USACCUM_MIN__ 0.0UHK #define __UHA_IBIT__ 8 #define __INT64_TYPE__ long long int #define __FLT_MAX_EXP__ 128 #define __UTQ_IBIT__ 0 #define __DBL_MANT_DIG__ 53 #define __INT_LEAST64_MAX__ 9223372036854775807LL #define __GCC_ATOMIC_CHAR16_T_LOCK_FREE 1 #define __DEC64_MIN__ 1E-383DD #define __WINT_TYPE__ unsigned int #define __UINT_LEAST32_TYPE__ unsigned int #define __SIZEOF_SHORT__ 2 #define __ULLFRACT_IBIT__ 0 #define __LDBL_MIN_EXP__ (-1021) #define __arm__ 1 #define __UDA_IBIT__ 32 #define __INT_LEAST8_MAX__ 127 #define __LFRACT_FBIT__ 31 #define __LDBL_MAX_10_EXP__ 308 #define __ATOMIC_RELAXED 0 #define __DBL_EPSILON__ ((double)2.2204460492503131e-16L) #define __UINT8_C(c) c #define __INT_LEAST32_TYPE__ int #define __SIZEOF_WCHAR_T__ 4 #define __UINT64_TYPE__ long long unsigned int #define __LLFRACT_MAX__ 0X7FFFFFFFFFFFFFFFP-63LLR #define __TQ_FBIT__ 127 #define __INT_FAST8_TYPE__ signed char #define __ULLACCUM_EPSILON__ 0x1P-32ULLK #define __UHQ_IBIT__ 0 #define __LLACCUM_IBIT__ 32 #define __DBL_DECIMAL_DIG__ 17 #define __DEC_EVAL_METHOD__ 2 #define __TA_FBIT__ 63 #define __UDQ_IBIT__ 0 #define __ORDER_BIG_ENDIAN__ 4321 #define __ACCUM_EPSILON__ 0x1P-15K #define __UINT32_C(c) c ## U #define __INTMAX_MAX__ 9223372036854775807LL #define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__ #define __FLT_DENORM_MIN__ 1.4012984643248171e-45F #define __LLFRACT_IBIT__ 0 #define __INT8_MAX__ 127 #define __UINT_FAST32_TYPE__ unsigned int #define __CHAR32_TYPE__ unsigned int #define __FLT_MAX__ 3.4028234663852886e+38F #define __USACCUM_FBIT__ 8 #define __INT32_TYPE__ int #define __SIZEOF_DOUBLE__ 8 #define __FLT_MIN_10_EXP__ (-37) #define __UFRACT_EPSILON__ 0x1P-16UR #define __INTMAX_TYPE__ long long int #define __DEC128_MAX_EXP__ 6145 #define __ATOMIC_CONSUME 1 #define __GNUC_MINOR__ 8 #define __UINTMAX_MAX__ 18446744073709551615ULL #define __DEC32_MANT_DIG__ 7 #define __HA_FBIT__ 7 #define __DBL_MAX_10_EXP__ 308 #define __LDBL_DENORM_MIN__ 4.9406564584124654e-324L #define __INT16_C(c) c #define __STDC__ 1 #define __PTRDIFF_TYPE__ int #define __LLFRACT_MIN__ (-0.5LLR-0.5LLR) #define __ATOMIC_SEQ_CST 5 #define __DA_FBIT__ 31 #define __UINT32_TYPE__ unsigned int #define __UINTPTR_TYPE__ unsigned int #define __USA_IBIT__ 16 #define __DEC64_SUBNORMAL_MIN__ 0.000000000000001E-383DD #define __ARM_EABI__ 1 #define __DEC128_MANT_DIG__ 34 #define __LDBL_MIN_10_EXP__ (-307) #define __SIZEOF_LONG_LONG__ 8 #define __ULACCUM_EPSILON__ 0x1P-32ULK #define __SACCUM_IBIT__ 8 #define __GCC_ATOMIC_LLONG_LOCK_FREE 1 #define __LDBL_DIG__ 15 #define __FLT_DECIMAL_DIG__ 9 #define __UINT_FAST16_MAX__ 4294967295U #define __GNUC_GNU_INLINE__ 1 #define __GCC_ATOMIC_SHORT_LOCK_FREE 1 #define __ULLFRACT_MAX__ 0XFFFFFFFFFFFFFFFFP-64ULLR #define __UINT_FAST8_TYPE__ unsigned char #define __USFRACT_EPSILON__ 0x1P-8UHR #define __ULACCUM_FBIT__ 32 #define __QQ_IBIT__ 0 #define __ATOMIC_ACQ_REL 4 #define __ATOMIC_RELEASE 3 mike@ubuntu:~/fsl-community-bsp/build/tmp/sysroots/x86_64-linux/usr/bin/cortexa9hf-vfp-neon-poky-linux-gnueabi$ On Jul 14, 2014, at 2:28 AM, Karel Gardas wrote:

On 07/12/14 07:27 AM, Michael Jones wrote:

...

Karel,

I have failed to figure out how to make this happen:

("target arch", "ArchARM {armISA = ARMv7, armISAExt = [VFPv3,NEON], armABI = HARD}”)

This is result of running ./configure on arm/ubuntu12.04 -- so I don't cross-compile, but rather compile natively. This is still preferred way to be able to run testsuite AFAIK...

...

I have added poky to the list of vendors in aclocal.m4 then configured like this:

/configure --target=arm-poky-linux-gnueabi --with-gcc=arm-poky-linux-gnueabi-gcc

But I end up with ARMv5.

I am new to Autotools and the Haskell build system, so I am not sure what controls this. I assume the idea is that the gcc cross-compiler compiles some code that checks for versions when it evaluates stuff like:

AC_COMPILE_IFELSE([ AC_LANG_PROGRAM( [], [#if defined(__ARM_ARCH_2__) || \ defined(__ARM_ARCH_3__) || \ defined(__ARM_ARCH_3M__) || \ defined(__ARM_ARCH_4__) || \ defined(__ARM_ARCH_4T__) || \

You arm-poky-linux-gnueabi-gcc -v tells what? Also arm-poky-linux-gnueabi-gcc -dM -E - < /dev/null may tell you something.

...

So I then suspect the compiler needs options like -mcpu=cortex-a9 -mfpu=neon to make the proper version defined, so that the code can check the architecture.

It depends on how the compiler is configured. -v will tell you. Mine looks like:

karel@panda:~$ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabi/4.6/lto-wrapper Target: arm-linux-gnueabi Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6.3-1ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --enable-multilib --disable-sjlj-exceptions --with-arch=armv7-a --with-float=softfp --with-fpu=vfpv3-d16 --with-mode=thumb --disable-werror --enable-checking=release --build=arm-linux-gnueabi --host=arm-linux-gnueabi --target=arm-linux-gnueabi Thread model: posix gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)

Please note --with-arch=armv7-a --with-float=softfp --with-fpu=vfpv3-d16 --with-mode=thumb -- I'm sure you will also be able to build a cross-compiler using those option, so it'll generate ARMv7A code by default, use just half of VFPv3 regs (VFPv3-D16) and generate Thumbs isns by default (not ARM).

Karel

I have some progress, and a problem. First, note I am using the 7.8.3 tar ball, for this discussion here. If you read through, you will see a request for help at the end. It looks like the cross compilation is trying to build stage2 when it shouldn’t. In order to get the resulting stage1 cross compiler to have: ,("target arch","ArchARM {armISA = ARMv7, armISAExt = [VFPv3,NEON], armABI = HARD}") I hacked this: AC_DEFUN([GET_ARM_ISA], [ changequote(, )dnl ARM_ISA=ARMv7 ARM_ISA_EXT="[VFPv3,NEON]" changequote([, ])dnl [ARM_ABI="HARD"] ]) Now, my gcc cross compiler does not default to ARMv7. To compile for my Cortex A, I add these options: -march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon -mtune=cortex-a9 So I need to make sure that when building the libraries with stage1, it passes the correct options. To do that: AC_DEFUN([FPTOOLS_SET_C_LD_FLAGS], [ AC_MSG_CHECKING([Setting up $2, $3, $4 and $5]) … arm-poky-*) $2="$$2 -march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon -mtune=cortex-a9" ;; Which results in a stage1 compiler with: ,("C compiler flags"," -march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon -mtune=cortex-a9 -fno-stack-protector”) As the build proceeds, all calls to stage1 are completing. Then, the build gets to this point: "inplace/bin/mkdirhier" compiler/stage2/build//. "rm" -f compiler/stage2/build/Config.hs Creating compiler/stage2/build/Config.hs ... done. And I assume this means it is trying to build stage2. Correct me if I am wrong. Eventually I get a build failure like this: gcc -E -DMAKING_GHC_BUILD_SYSTEM_DEPENDENCIES -march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon -mtune=cortex-a9 -fno-stack-protector -Icompiler/. -Icompiler/parser -Icompiler/utils -Icompiler/../rts/dist/build -Icompiler/stage2 -DGHCI -I'/home/mike/ghc-7.8.3/libraries/process/include' -I'/home/mike/ghc-7.8.3/libraries/directory/include' -I'/home/mike/ghc-7.8.3/libraries/unix/include' -I'/home/mike/ghc-7.8.3/libraries/time/include' -I'/home/mike/ghc-7.8.3/libraries/containers/include' -I'/home/mike/ghc-7.8.3/libraries/bytestring/include' -I'/home/mike/ghc-7.8.3/libraries/base/include' -I'/home/mike/ghc-7.8.3/rts/dist/build' -I'/home/mike/ghc-7.8.3/includes' -I'/home/mike/ghc-7.8.3/includes/dist-derivedconstants/header' -MM -x c compiler/parser/cutils.c -MF compiler/stage2/build/.depend-v.c_asm.bit gcc: error: unrecognized command line option ‘-mthumb-interwork’ gcc: error: unrecognized command line option ‘-mfloat-abi=hard’ gcc: error: unrecognized command line option ‘-mfpu=neon’ make[1]: *** [compiler/stage2/build/.depend-v.c_asm] Error 1 make: *** [all] Error 2 It is applying the -march… arguments to the local gcc. I am guessing that compiling for stage2 is using the local gcc because stage2 is only built when not making a cross compiler. Now, in build.mk I have: BuildFlavour = quick-cross Which is supposed to prevent stage2 compilation. Something is wrong. Either I need to stop stage2 compilation, if that is what this is really doing, or prevent gcc from using the extra arguments. But I see no reason to run gcc. Seems like that would only be used at stage0 if at all. Mike On Jul 14, 2014, at 10:12 AM, Karel Gardas wrote:

On 07/14/14 04:58 PM, Michael Jones wrote:

...

Karel,

Thanks. This helps.

If I understand, you have Linux running on a Panda, and on that Panda system you have gcc, and you compile GHC on the Panda itself, rather than build a cross compiler. I can see the advantage of building this way.

Correct!

...

As far as cross compilers, I have a reason for trying to build a cross compiler, other than the ability to keep the image of the target small. That is, eventually, I want to be able to compile for an RTOS and/or bare iron system. I decided that learning to cross compile for Linux first would be a good approach. Learn the build system on something known to work. So I probably will not give up on that.

That is right, in future I'd also like to give a try to port GHC to some free RTOS and for this I'd need to use cross-compiling anyway, so I'll be on the same boat...

...

I got a book on Autoconfig. I’ll just have to dig a level deeper into the whole build system. Mainly it means learning the M4 system. I have never used it.

Below are the defines from the command you suggested. Thanks for that, got me over an ignorance hump. At least this define, __ARM_ARCH_5T__, is in the aclocal.m4 file. So I will have to study the macros until I figure out what controls the gcc options passed to the gcc cross compiler. I guess my question is what actually controls this result ("target arch", "ArchARM {armISA = ARMv7, armISAExt = [VFPv3,NEON], armABI = HARD}”)?

Are these controlled by the defines below, or are they controlled by passing gcc arguments to the gcc compiler when the Haskell compiler calls gcc?

Basically speaking all those are controlled by platform gcc. That means if you pass the right option to your cross-compiling gcc you should also get the same result, so for example if you use:

gcc -mfloat-abi=hard -march=armv7-a -mfpu=vfpv3-d16

you should get the same settings like me.

But anyway, please note that ABI you set to your cross-compiler *have to* match the ABI provided by the target RTOS/OS! I hope that's clear. :-)

Cheers, Karel

Karel, On CFLAGS.. When the cross compiler is compiled, does it use gcc, or is gcc only used to compile libraries with the stage-1 compiler? Because if gcc is used for both, I would need different flags for each, and I don't know how to make that happen. Mike Sent from my iPad

On Aug 1, 2014, at 3:19 AM, Karel Gardas wrote:

OK, so you do have ghc-stage1 which is a cross-compiler. Now, what does ghc-stage1 --info tell you?

Aha, you hacked configure, hmm. I don't think this is needed especially if you use proper CFLAGS.

Karel

...

On 07/25/14 06:00 AM, Michael Jones wrote: I have some progress, and a problem. First, note I am using the 7.8.3 tar ball, for this discussion here.

If you read through, you will see a request for help at the end. It looks like the cross compilation is trying to build stage2 when it shouldn’t.

In order to get the resulting stage1 cross compiler to have:

,("target arch","ArchARM {armISA = ARMv7, armISAExt = [VFPv3,NEON], armABI = HARD}")

I hacked this:

AC_DEFUN([GET_ARM_ISA], [ changequote(, )dnl ARM_ISA=ARMv7 ARM_ISA_EXT="[VFPv3,NEON]" changequote([, ])dnl [ARM_ABI="HARD"] ])

Now, my gcc cross compiler does not default to ARMv7. To compile for my Cortex A, I add these options:

-march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon -mtune=cortex-a9

So I need to make sure that when building the libraries with stage1, it passes the correct options. To do that:

AC_DEFUN([FPTOOLS_SET_C_LD_FLAGS], [ AC_MSG_CHECKING([Setting up $2, $3, $4 and $5]) … arm-poky-*) $2="$$2 -march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon -mtune=cortex-a9" ;;

Which results in a stage1 compiler with:

,("C compiler flags"," -march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon -mtune=cortex-a9 -fno-stack-protector”)

As the build proceeds, all calls to stage1 are completing. Then, the build gets to this point:

"inplace/bin/mkdirhier" compiler/stage2/build//. "rm" -f compiler/stage2/build/Config.hs Creating compiler/stage2/build/Config.hs ... done.

And I assume this means it is trying to build stage2. Correct me if I am wrong.

Eventually I get a build failure like this:

gcc -E -DMAKING_GHC_BUILD_SYSTEM_DEPENDENCIES -march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon -mtune=cortex-a9 -fno-stack-protector -Icompiler/. -Icompiler/parser -Icompiler/utils -Icompiler/../rts/dist/build -Icompiler/stage2 -DGHCI -I'/home/mike/ghc-7.8.3/libraries/process/include' -I'/home/mike/ghc-7.8.3/libraries/directory/include' -I'/home/mike/ghc-7.8.3/libraries/unix/include' -I'/home/mike/ghc-7.8.3/libraries/time/include' -I'/home/mike/ghc-7.8.3/libraries/containers/include' -I'/home/mike/ghc-7.8.3/libraries/bytestring/include' -I'/home/mike/ghc-7.8.3/libraries/base/include' -I'/home/mike/ghc-7.8.3/rts/dist/build' -I'/home/mike/ghc-7.8.3/includes' -I'/home/mike/ghc-7.8.3/includes/dist-derivedconstants/header' -MM -x c compiler/parser/cutils.c -MF compiler/stage2/build/.depend-v.c_asm.bit gcc: error: unrecognized command line option ‘-mthumb-interwork’ gcc: error: unrecognized command line option ‘-mfloat-abi=hard’ gcc: error: unrecognized command line option ‘-mfpu=neon’ make[1]: *** [compiler/stage2/build/.depend-v.c_asm] Error 1 make: *** [all] Error 2

It is applying the -march… arguments to the local gcc. I am guessing that compiling for stage2 is using the local gcc because stage2 is only built when not making a cross compiler.

Now, in build.mk I have:

BuildFlavour = quick-cross

Which is supposed to prevent stage2 compilation.

Something is wrong. Either I need to stop stage2 compilation, if that is what this is really doing, or prevent gcc from using the extra arguments. But I see no reason to run gcc. Seems like that would only be used at stage0 if at all.

Mike

On Jul 14, 2014, at 10:12 AM, Karel Gardas mailto:karel.gardas@centrum.cz> wrote:

...

...

On 07/14/14 04:58 PM, Michael Jones wrote: Karel,

Thanks. This helps.

If I understand, you have Linux running on a Panda, and on that Panda system you have gcc, and you compile GHC on the Panda itself, rather than build a cross compiler. I can see the advantage of building this way.

Correct!

...

As far as cross compilers, I have a reason for trying to build a cross compiler, other than the ability to keep the image of the target small. That is, eventually, I want to be able to compile for an RTOS and/or bare iron system. I decided that learning to cross compile for Linux first would be a good approach. Learn the build system on something known to work. So I probably will not give up on that.

That is right, in future I'd also like to give a try to port GHC to some free RTOS and for this I'd need to use cross-compiling anyway, so I'll be on the same boat...

...

I got a book on Autoconfig. I’ll just have to dig a level deeper into the whole build system. Mainly it means learning the M4 system. I have never used it.

Below are the defines from the command you suggested. Thanks for that, got me over an ignorance hump. At least this define, __ARM_ARCH_5T__, is in the aclocal.m4 file. So I will have to study the macros until I figure out what controls the gcc options passed to the gcc cross compiler. I guess my question is what actually controls this result ("target arch", "ArchARM {armISA = ARMv7, armISAExt = [VFPv3,NEON], armABI = HARD}”)?

Are these controlled by the defines below, or are they controlled by passing gcc arguments to the gcc compiler when the Haskell compiler calls gcc?

Basically speaking all those are controlled by platform gcc. That means if you pass the right option to your cross-compiling gcc you should also get the same result, so for example if you use:

gcc -mfloat-abi=hard -march=armv7-a -mfpu=vfpv3-d16

you should get the same settings like me.

But anyway, please note that ABI you set to your cross-compiler *have to* match the ABI provided by the target RTOS/OS! I hope that's clear. :-)

Cheers, Karel

Karel, I was able to get GHC to compile by rebuilding the gcc cross compiler using —with-arch= and —with-tune= However, it is not a satisfactory solution, because if a gcc toolchain uses multilibs, adding those options does not make sense. In the case of the Yocto toolchain, it does not use multilibs, so I can get away with it. I’ll test the compiler tomorrow and see how things go. Here is the GHC info after building: [("Project name","The Glorious Glasgow Haskell Compilation System") ,("GCC extra via C opts"," -fwrapv") ,("C compiler command","arm-poky-linux-gnueabi-gcc") ,("C compiler flags"," -fno-stack-protector") ,("C compiler link flags","") ,("Haskell CPP command","arm-poky-linux-gnueabi-gcc") ,("Haskell CPP flags","-E -undef -traditional ") ,("ld command","/home/mike/fsl-community-bsp/build/tmp/sysroots/x86_64-linux/usr/bin/cortexa9hf-vfp-neon-poky-linux-gnueabi/arm-poky-linux-gnueabi-ld") ,("ld flags","") ,("ld supports compact unwind","YES") ,("ld supports build-id","YES") ,("ld supports filelist","NO") ,("ld is GNU ld","YES") ,("ar command","/home/mike/fsl-community-bsp/build/tmp/sysroots/x86_64-linux/usr/bin/cortexa9hf-vfp-neon-poky-linux-gnueabi/arm-poky-linux-gnueabi-ar") ,("ar flags","q") ,("ar supports at file","YES") ,("touch command","touch") ,("dllwrap command","/bin/false") ,("windres command","/bin/false") ,("libtool command","libtool") ,("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") ,("Unregisterised","NO") ,("LLVM llc command","/usr/bin/llc") ,("LLVM opt command","/usr/bin/opt") ,("Project version","7.8.3") ,("Booter version","7.6.3") ,("Stage","1") ,("Build platform","x86_64-unknown-linux") ,("Host platform","x86_64-unknown-linux") ,("Target platform","arm-poky-linux") ,("Have interpreter","YES") ,("Object splitting supported","NO") ,("Have native code generator","NO") ,("Support SMP","YES") ,("Tables next to code","YES") ,("RTS ways","l debug thr thr_debug thr_l ") ,("Support dynamic-too","YES") ,("Support parallel --make","YES") ,("Dynamic by default","NO") ,("GHC Dynamic","NO") ,("Leading underscore","NO") ,("Debug on","False") ,("LibDir","/home/mike/ghc-7.8.3/inplace/lib") ,("Global Package DB","/home/mike/ghc-7.8.3/inplace/lib/package.conf.d") ] On Aug 1, 2014, at 8:02 PM, Michael Jones wrote:

Karel,

I think I proved that make dies early if CFLAGS has these options. The local gcc does not support ARM related flags.

I am trying to build the tool chain with —with-arch= and —with-tune== so that it defaults to my target. This will bypass any GHC build issues.

Mike

On Aug 1, 2014, at 3:23 PM, Michael Jones wrote:

...

Karel,

On CFLAGS..

When the cross compiler is compiled, does it use gcc, or is gcc only used to compile libraries with the stage-1 compiler?

Because if gcc is used for both, I would need different flags for each, and I don't know how to make that happen.

Mike

Sent from my iPad

...

On Aug 1, 2014, at 3:19 AM, Karel Gardas wrote:

OK, so you do have ghc-stage1 which is a cross-compiler. Now, what does ghc-stage1 --info tell you?

Aha, you hacked configure, hmm. I don't think this is needed especially if you use proper CFLAGS.

Karel

...

On 07/25/14 06:00 AM, Michael Jones wrote: I have some progress, and a problem. First, note I am using the 7.8.3 tar ball, for this discussion here.

If you read through, you will see a request for help at the end. It looks like the cross compilation is trying to build stage2 when it shouldn’t.

In order to get the resulting stage1 cross compiler to have:

,("target arch","ArchARM {armISA = ARMv7, armISAExt = [VFPv3,NEON], armABI = HARD}")

I hacked this:

AC_DEFUN([GET_ARM_ISA], [ changequote(, )dnl ARM_ISA=ARMv7 ARM_ISA_EXT="[VFPv3,NEON]" changequote([, ])dnl [ARM_ABI="HARD"] ])

Now, my gcc cross compiler does not default to ARMv7. To compile for my Cortex A, I add these options:

-march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon -mtune=cortex-a9

So I need to make sure that when building the libraries with stage1, it passes the correct options. To do that:

AC_DEFUN([FPTOOLS_SET_C_LD_FLAGS], [ AC_MSG_CHECKING([Setting up $2, $3, $4 and $5]) … arm-poky-*) $2="$$2 -march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon -mtune=cortex-a9" ;;

Which results in a stage1 compiler with:

,("C compiler flags"," -march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon -mtune=cortex-a9 -fno-stack-protector”)

As the build proceeds, all calls to stage1 are completing. Then, the build gets to this point:

"inplace/bin/mkdirhier" compiler/stage2/build//. "rm" -f compiler/stage2/build/Config.hs Creating compiler/stage2/build/Config.hs ... done.

And I assume this means it is trying to build stage2. Correct me if I am wrong.

Eventually I get a build failure like this:

gcc -E -DMAKING_GHC_BUILD_SYSTEM_DEPENDENCIES -march=armv7-a -mthumb-interwork -mfloat-abi=hard -mfpu=neon -mtune=cortex-a9 -fno-stack-protector -Icompiler/. -Icompiler/parser -Icompiler/utils -Icompiler/../rts/dist/build -Icompiler/stage2 -DGHCI -I'/home/mike/ghc-7.8.3/libraries/process/include' -I'/home/mike/ghc-7.8.3/libraries/directory/include' -I'/home/mike/ghc-7.8.3/libraries/unix/include' -I'/home/mike/ghc-7.8.3/libraries/time/include' -I'/home/mike/ghc-7.8.3/libraries/containers/include' -I'/home/mike/ghc-7.8.3/libraries/bytestring/include' -I'/home/mike/ghc-7.8.3/libraries/base/include' -I'/home/mike/ghc-7.8.3/rts/dist/build' -I'/home/mike/ghc-7.8.3/includes' -I'/home/mike/ghc-7.8.3/includes/dist-derivedconstants/header' -MM -x c compiler/parser/cutils.c -MF compiler/stage2/build/.depend-v.c_asm.bit gcc: error: unrecognized command line option ‘-mthumb-interwork’ gcc: error: unrecognized command line option ‘-mfloat-abi=hard’ gcc: error: unrecognized command line option ‘-mfpu=neon’ make[1]: *** [compiler/stage2/build/.depend-v.c_asm] Error 1 make: *** [all] Error 2

It is applying the -march… arguments to the local gcc. I am guessing that compiling for stage2 is using the local gcc because stage2 is only built when not making a cross compiler.

Now, in build.mk I have:

BuildFlavour = quick-cross

Which is supposed to prevent stage2 compilation.

Something is wrong. Either I need to stop stage2 compilation, if that is what this is really doing, or prevent gcc from using the extra arguments. But I see no reason to run gcc. Seems like that would only be used at stage0 if at all.

Mike

On Jul 14, 2014, at 10:12 AM, Karel Gardas mailto:karel.gardas@centrum.cz> wrote:

...

...

On 07/14/14 04:58 PM, Michael Jones wrote: Karel,

Thanks. This helps.

If I understand, you have Linux running on a Panda, and on that Panda system you have gcc, and you compile GHC on the Panda itself, rather than build a cross compiler. I can see the advantage of building this way.

Correct!

...

As far as cross compilers, I have a reason for trying to build a cross compiler, other than the ability to keep the image of the target small. That is, eventually, I want to be able to compile for an RTOS and/or bare iron system. I decided that learning to cross compile for Linux first would be a good approach. Learn the build system on something known to work. So I probably will not give up on that.

That is right, in future I'd also like to give a try to port GHC to some free RTOS and for this I'd need to use cross-compiling anyway, so I'll be on the same boat...

...

I got a book on Autoconfig. I’ll just have to dig a level deeper into the whole build system. Mainly it means learning the M4 system. I have never used it.

Below are the defines from the command you suggested. Thanks for that, got me over an ignorance hump. At least this define, __ARM_ARCH_5T__, is in the aclocal.m4 file. So I will have to study the macros until I figure out what controls the gcc options passed to the gcc cross compiler. I guess my question is what actually controls this result ("target arch", "ArchARM {armISA = ARMv7, armISAExt = [VFPv3,NEON], armABI = HARD}”)?

Are these controlled by the defines below, or are they controlled by passing gcc arguments to the gcc compiler when the Haskell compiler calls gcc?

Basically speaking all those are controlled by platform gcc. That means if you pass the right option to your cross-compiling gcc you should also get the same result, so for example if you use:

gcc -mfloat-abi=hard -march=armv7-a -mfpu=vfpv3-d16

you should get the same settings like me.

But anyway, please note that ABI you set to your cross-compiler *have to* match the ABI provided by the target RTOS/OS! I hope that's clear. :-)

Cheers, Karel

_______________________________________________ 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

Karel, My configure hack is now limited to two hacks on GHC 7.8.3. The vendor “pokey", and the ARM settings that make the target architecture correct. I also enabled profiling in build.mk. So pretty clean. No compiler options. GHC compiles clean. I am getting a stack overflow during execution of the hello world applicaiton. I compiled like: arm-poky-linux-gnueabi-ghc -static -debug -auto-all -caf-all -prof Main.hs I ran on the target like: ./Main +RTS -Ds -Di -Db -DS -Dt -Da 2>log I attached a log. Search for overflow. created capset 0 of type 2 created capset 1 of type 3 cap 0: initialised assigned cap 0 to capset 0 assigned cap 0 to capset 1 free block list [0]: free block list [1]: free block list [2]: free block list [3]: free block list [4]: free block list [5]: free block list [6]: group at 0x76c82000, length 126 blocks free block list [7]: free block list [8]: free block list [0]: free block list [1]: free block list [2]: free block list [3]: free block list [4]: free block list [5]: free block list [6]: group at 0x76c82000, length 126 blocks free block list [7]: free block list [8]: free block list [0]: free block list [1]: free block list [2]: free block list [3]: free block list [4]: free block list [5]: free block list [6]: group at 0x76c82000, length 125 blocks free block list [7]: free block list [8]: free block list [0]: free block list [1]: free block list [2]: free block list [3]: free block list [4]: free block list [5]: free block list [6]: group at 0x76c82000, length 124 blocks free block list [7]: free block list [8]: free block list [0]: free block list [1]: free block list [2]: free block list [3]: free block list [4]: free block list [5]: free block list [6]: group at 0x76c82000, length 123 blocks free block list [7]: free block list [8]: free block list [0]: free block list [1]: free block list [2]: free block list [3]: free block list [4]: free block list [5]: free block list [6]: group at 0x76c82000, length 122 blocks free block list [7]: free block list [8]: new task (taskCount: 1) cap 0: created thread 1 new bound thread (1) cap 0: schedule() cap 0: running thread 1 (ThreadRunGHC) stg_ap_v_ret... PAP/1(0x5ba25a, 0x5a3670) stg_ap_0_ret... base:GHC.MVar.MVar(0x76c020d4) stg_ap_v_ret... (0xa964, CAF:main) stg_ap_v_ret... PAP/1(0x5bce1a, 0x76c02160) stg_ap_0_ret... ghc-prim:GHC.Tuple.(,)(0x76c021a9, 0x76c0219a) stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c023d1, 0x76c023be) cap 0: thread 1 stopped (yielding) cap 0: running thread 1 (ThreadRunGHC) stg_ap_0_ret... base:GHC.IO.Encoding.Types.TextEncoding(0x5aadd0, 0x76c026c5, 0x76c02665) stg_ap_v_ret... (0x59458, CAF) stg_ap_0_ret... ghc-prim:GHC.Tuple.(,)(0x76c029a1, 0x76c02992) stg_ap_0_ret... FUN/1(0x59088, CAF, 0x76c02980) stg_ap_v_ret... FUN/1(0x59088, CAF, 0x76c02980) stg_ap_0_ret... base:GHC.IO.Encoding.Types.TextEncoding(0x5aadd0, 0x76c02aa1, 0x76c02a41) stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c023d1, 0x76c02b40) stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c023ad, 0x76c02ba8) stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c02389, 0x76c02c10) stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c02365, 0x76c02c78) stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c02341, 0x76c02ce0) stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c0231d, 0x76c02d48) stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c022f9, 0x76c02db0) stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c022d5, 0x76c02e18) stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c022b1, 0x76c02e80) stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c0228d, 0x76c02ee8) stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c02269, 0x76c02f50) stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c02245, 0x76c02fb8) stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c02221, 0x76c0502c) stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c021fd, 0x76c05094) stg_ap_0_ret... ghc-prim:GHC.Types.[]() stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c02b14) stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c02b7c) stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c02be4) stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c02c4c) stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c02cb4) stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c02d1c) stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c02d84) stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c02dec) stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c02e54) stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c02ebc) stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c02f24) stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c02f8c) stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c05000) stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c05068) stg_ap_0_ret... ghc-prim:GHC.Types.[]() stg_ap_v_ret... IND_STATIC(0x76c0360c) stg_ap_v_ret... FUN/1(0x59088, CAF, 0x76c02980) stg_ap_v_ret... IND_STATIC(0x76c0360c) stg_ap_v_ret... FUN/1(0x59088, CAF, 0x76c02980) stg_ap_v_ret... IND_STATIC(0x76c0360c) stg_ap_v_ret... FUN/1(0x59088, CAF, 0x76c02980) stg_ap_v_ret... IND_STATIC(0x76c0360c) stg_ap_v_ret... FUN/1(0x59088, CAF, 0x76c02980) stg_ap_v_ret... IND_STATIC(0x76c0360c) stg_ap_v_ret... FUN/1(0x59088, CAF, 0x76c02980) stg_ap_v_ret... IND_STATIC(0x76c0360c) stg_ap_v_ret... FUN/1(0x59088, CAF, 0x76c02980) cap 0: thread 1 stopped (stack overflow) On Aug 2, 2014, at 12:07 PM, Karel Gardas wrote:

On 08/ 2/14 07:04 AM, Michael Jones wrote:

...

,("target arch","ArchARM {armISA = ARMv7, armISAExt = [VFPv3,NEON], armABI = HARD}") ,("target word size","4")

this looks good, but I hope you got it on clean tree, i.e. without your configure hack...

Karel

I ran the same program on my dev linux and compared it to see if there were clues. On my dev box (Ubuntu) here are some snippets of the log (working app) new task (taskCount: 1) cap 0: created thread 1 new bound thread (1) cap 0: schedule() cap 0: running thread 1 (ThreadRunGHC) New weak pointer at 0x7f7788704050 stg_ap_0_ret... base:GHC.MVar.MVar(0x7f7788704148) stg_ap_0_ret... ghc-prim:GHC.Tuple.(,)(0x7f7788704281, 0x7f7788704272) stg_ap_0_ret... ghc-prim:GHC.Types.:(0x7f7788704421, 0x7f778870440a) New weak pointer at 0x7f7788706188 stg_ap_0_ret... base:GHC.IO.Handle.Types.FileHandle(0x6d4080, 0x7f77887060b0) And on the failing embedded target: new task (taskCount: 1) cap 0: created thread 1 new bound thread (1) cap 0: schedule() cap 0: running thread 1 (ThreadRunGHC) New weak pointer at 0x76c02038 stg_ap_0_ret... base:GHC.MVar.MVar(0x76c020d4) stg_ap_0_ret... ghc-prim:GHC.Tuple.(,)(0x76c021a9, 0x76c0219a) cap 0: thread 1 stopped (yielding) cap 0: running thread 1 (ThreadRunGHC) stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c023d1, 0x76c023be) stg_ap_0_ret... ghc-prim:GHC.Tuple.(,)(0x76c029a1, 0x76c02992) stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c05068) stg_ap_0_ret... ghc-prim:GHC.Types.[]() stg_ap_v_ret... IND_STATIC(0x76c0360c) stg_ap_v_ret... FUN/1(0x59088, CAF, 0x76c02980) cap 0: thread 1 stopped (stack overflow) A couple of things are different in the failing target. First, the thread yields, and then is allowed to run, whereas on Ubuntu it just runs to completion. Second, there is a second set of primitive calls: stg_ap_0_ret... ghc-prim:GHC.Tuple.(,)(0x76c029a1, 0x76c02992) stg_ap_0_ret... ghc-prim:GHC.Types.[]() cap 0: thread 1 stopped (stack overflow) And this is followed by the stack overflow. These two calls are not present when run on Ubuntu. The original source is: module Main where main::IO() main = putStr "Hello world!” As a reminder, the difference is: Working: Standard GHC on Ubuntu Failing: Cross compiled for Cortex A and run on Wandboard with Yocto Linux Do these extra two calls give any clues to the cause of the stack flow? The other thing to note, is the working version eventually gets to various IO calls. These are never reached in the failing version. So it seems to be choking in the type system code before it gets to IO. Is there a test program that could be run that might narrow down the problem? Mike On Aug 4, 2014, at 8:23 AM, Michael Jones wrote:

To be complete, there is an old link on compiling for arm, and it recommends this build process:

$ chmod ugo+rx build-ghc-arm.sh Edit build-ghc-arm.sh to fix EOF $ ./build-ghc-arm.sh -j4 $ make test $ sudo make install $ arm-poky-linux-gnueabi-ghc --info

This way of building produces the same result as below. So I am guessing that problems that this fixed moons ago no longer exist, or produce different problems that are masked.

What will help me, not knowing the RTS, is if anyone can recognize the failure pattern and give me some hints where in the code the problem might be. That way I can add some logging specifically related to the problem to get more data, and limit my study of the RTS code to a specific set of files.

My other thought is if there is some test code that might help reveal the problem. Something that if it runs, and the log is clean, perhaps eliminates possible problems. The RTS is able to write a log via stdio, so that could be exploited to run test code that can log information. But the hello world fails to write to stdio. So perhaps the problem occurs in the start up phase where the thread is created and things go wrong before hello world is executed. This would suggest any test code would have to be run within the RTS itself. Is there some way to enable some ASSERTIONS within RTS that would help narrow down the problem?

Also, is there any way to compile up something small to run the RTS without any Haskell libraries, etc, so and debug it with a C/C++ debugger? I am able to debug other C/C++ programs on the target device, so if I had a C/C++ program, code, etc, I could run and debug it.

Mike

On Aug 2, 2014, at 4:04 PM, Michael Jones wrote:

...

Karel,

My configure hack is now limited to two hacks on GHC 7.8.3. The vendor “pokey", and the ARM settings that make the target architecture correct. I also enabled profiling in build.mk. So pretty clean. No compiler options. GHC compiles clean.

I am getting a stack overflow during execution of the hello world applicaiton. I compiled like:

arm-poky-linux-gnueabi-ghc -static -debug -auto-all -caf-all -prof Main.hs

I ran on the target like:

./Main +RTS -Ds -Di -Db -DS -Dt -Da 2>log

I attached a log. Search for overflow.

created capset 0 of type 2 created capset 1 of type 3 cap 0: initialised assigned cap 0 to capset 0 assigned cap 0 to capset 1 free block list [0]: free block list [1]: free block list [2]: free block list [3]: free block list [4]: free block list [5]: free block list [6]: group at 0x76c82000, length 126 blocks free block list [7]: free block list [8]: free block list [0]: free block list [1]: free block list [2]: free block list [3]: free block list [4]: free block list [5]: free block list [6]: group at 0x76c82000, length 126 blocks free block list [7]: free block list [8]: free block list [0]: free block list [1]: free block list [2]: free block list [3]: free block list [4]: free block list [5]: free block list [6]: group at 0x76c82000, length 125 blocks free block list [7]: free block list [8]: free block list [0]: free block list [1]: free block list [2]: free block list [3]: free block list [4]: free block list [5]: free block list [6]: group at 0x76c82000, length 124 blocks free block list [7]: free block list [8]: free block list [0]: free block list [1]: free block list [2]: free block list [3]: free block list [4]: free block list [5]: free block list [6]: group at 0x76c82000, length 123 blocks free block list [7]: free block list [8]: free block list [0]: free block list [1]: free block list [2]: free block list [3]: free block list [4]: free block list [5]: free block list [6]: group at 0x76c82000, length 122 blocks free block list [7]: free block list [8]: new task (taskCount: 1) cap 0: created thread 1 new bound thread (1) cap 0: schedule() cap 0: running thread 1 (ThreadRunGHC) stg_ap_v_ret... PAP/1(0x5ba25a, 0x5a3670) stg_ap_0_ret... base:GHC.MVar.MVar(0x76c020d4) stg_ap_v_ret... (0xa964, CAF:main) stg_ap_v_ret... PAP/1(0x5bce1a, 0x76c02160) stg_ap_0_ret... ghc-prim:GHC.Tuple.(,)(0x76c021a9, 0x76c0219a) stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c023d1, 0x76c023be) cap 0: thread 1 stopped (yielding) cap 0: running thread 1 (ThreadRunGHC) stg_ap_0_ret... base:GHC.IO.Encoding.Types.TextEncoding(0x5aadd0, 0x76c026c5, 0x76c02665) stg_ap_v_ret... (0x59458, CAF) stg_ap_0_ret... ghc-prim:GHC.Tuple.(,)(0x76c029a1, 0x76c02992) stg_ap_0_ret... FUN/1(0x59088, CAF, 0x76c02980) stg_ap_v_ret... FUN/1(0x59088, CAF, 0x76c02980) stg_ap_0_ret... base:GHC.IO.Encoding.Types.TextEncoding(0x5aadd0, 0x76c02aa1, 0x76c02a41) stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c023d1, 0x76c02b40) stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c023ad, 0x76c02ba8) stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c02389, 0x76c02c10) stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c02365, 0x76c02c78) stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c02341, 0x76c02ce0) stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c0231d, 0x76c02d48) stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c022f9, 0x76c02db0) stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c022d5, 0x76c02e18) stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c022b1, 0x76c02e80) stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c0228d, 0x76c02ee8) stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c02269, 0x76c02f50) stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c02245, 0x76c02fb8) stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c02221, 0x76c0502c) stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c021fd, 0x76c05094) stg_ap_0_ret... ghc-prim:GHC.Types.[]() stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c02b14) stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c02b7c) stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c02be4) stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c02c4c) stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c02cb4) stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c02d1c) stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c02d84) stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c02dec) stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c02e54) stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c02ebc) stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c02f24) stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c02f8c) stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c05000) stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c05068) stg_ap_0_ret... ghc-prim:GHC.Types.[]() stg_ap_v_ret... IND_STATIC(0x76c0360c) stg_ap_v_ret... FUN/1(0x59088, CAF, 0x76c02980) stg_ap_v_ret... IND_STATIC(0x76c0360c) stg_ap_v_ret... FUN/1(0x59088, CAF, 0x76c02980) stg_ap_v_ret... IND_STATIC(0x76c0360c) stg_ap_v_ret... FUN/1(0x59088, CAF, 0x76c02980) stg_ap_v_ret... IND_STATIC(0x76c0360c) stg_ap_v_ret... FUN/1(0x59088, CAF, 0x76c02980) stg_ap_v_ret... IND_STATIC(0x76c0360c) stg_ap_v_ret... FUN/1(0x59088, CAF, 0x76c02980) stg_ap_v_ret... IND_STATIC(0x76c0360c) stg_ap_v_ret... FUN/1(0x59088, CAF, 0x76c02980) cap 0: thread 1 stopped (stack overflow) On Aug 2, 2014, at 12:07 PM, Karel Gardas wrote:

...

On 08/ 2/14 07:04 AM, Michael Jones wrote:

...

,("target arch","ArchARM {armISA = ARMv7, armISAExt = [VFPv3,NEON], armABI = HARD}") ,("target word size","4")

this looks good, but I hope you got it on clean tree, i.e. without your configure hack...

Karel

_______________________________________________ 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