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 <m...@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.schonw...@gmail.com>
> wrote:
>
> could you share the output of ghc --info?
>
>
> On Tue, Jul 8, 2014 at 12:10 AM, Michael Jones <m...@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
>> 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
