Cross compiling for Cortex A9

Tue Jul 8 06:03:41 UTC 2014

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 <mike at proclivis.com> 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 <carter.schonwald at gmail.com>
> wrote:
>
> could you share the output of ghc --info?
>
>
> On Tue, Jul 8, 2014 at 12:10 AM, Michael Jones <mike at 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 at haskell.org
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140708/200869b1/attachment.html>