<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div style="-webkit-text-size-adjust: auto;">That doc says:</div><div style="-webkit-text-size-adjust: auto;"><br></div><div><p><span style="-webkit-text-size-adjust: auto; background-color: rgba(255, 255, 255, 0);">...This will usually manifest itself as a failure of <code style="border: 1px solid rgb(200, 200, 200);">dll-split</code> during the build process with <code style="border: 1px solid rgb(200, 200, 200);">internal error: evacuate(static): strange closure type 0</code>.</span></p><p><span style="-webkit-text-size-adjust: auto;">Which does not happen when I build.</span></p><p><span style="-webkit-text-size-adjust: auto; background-color: rgba(255, 255, 255, 0);">Until this is fixed, the newer <a href="https://en.wikipedia.org/wiki/Gold_%28linker%29" style="text-decoration: none;">gold</a> linker will be the only supported linker with GHC on ARM (at least when tables-next-to-code is enabled). GHC now <a href="https://github.com/bgamari/ghc/commit/53856a43d9d1a901f70d96d22a31c6ea56903e0e" style="text-decoration: none;">checks</a> that the linker being used isn’t affected by the bug in question, so hopefully users won’t be affected beyond needing to switch linkers.</span></p><div style="-webkit-text-size-adjust: auto;">And I don't get an error indicating this bug unless it is a warning missed in the massive build output.</div><div style="-webkit-text-size-adjust: auto;"><br></div><div style="-webkit-text-size-adjust: auto;">So I assumed all was fixed. Nonetheless, I'll dig into the linker notes a bit more. Perhaps I should just try the gold linker if Ben does not respond to this enquiry.</div><div style="-webkit-text-size-adjust: auto;"><br></div><div style="-webkit-text-size-adjust: auto;">Mike</div><br><span style="-webkit-text-size-adjust: auto;">Sent from my iPad</span></div><div style="-webkit-text-size-adjust: auto;"><br>On Jul 8, 2014, at 12:03 AM, Carter Schonwald <<a href="mailto:carter.schonwald@gmail.com">carter.schonwald@gmail.com</a>> wrote:<br><br></div><blockquote type="cite" style="-webkit-text-size-adjust: auto;"><div><div dir="ltr">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 <a href="http://bgamari.github.io/posts/2014-03-06-compiling-ghc-7.8-on-arm.html">http://bgamari.github.io/posts/2014-03-06-compiling-ghc-7.8-on-arm.html</a>  )<div>

<br></div><div><span style="font-family:arial,sans-serif;font-size:13px"> ,("ld command","arm-poky-linux-</span><span style="font-family:arial,sans-serif;font-size:13px">gnueabi-ld") </span><br></div>
<div>
<span style="font-family:arial,sans-serif;font-size:13px">is that GOLD?</span></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jul 8, 2014 at 1:51 AM, Michael Jones <span dir="ltr"><<a href="mailto:mike@proclivis.com" target="_blank">mike@proclivis.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>I am pasting both the info from the HOST and TARGET compilers:</div><div><br></div>

<div>HOST</div><div>====</div><div><br></div><div><div> [("Project name","The Glorious Glasgow Haskell Compilation System")</div><div> ,("GCC extra via C opts"," -fwrapv")</div><div>

 ,("C compiler command","/usr/bin/gcc")</div><div> ,("C compiler flags"," -fno-stack-protector  -Wl,--hash-size=31 -Wl,--reduce-memory-overheads")</div><div> ,("ar command","/usr/bin/ar")</div>

<div> ,("ar flags","q")</div><div> ,("ar supports at file","YES")</div><div> ,("touch command","touch")</div><div> ,("dllwrap command","/bin/false")</div>

<div> ,("windres command","/bin/false")</div><div> ,("perl command","/usr/bin/perl")</div><div> ,("target os","OSLinux")</div><div> ,("target arch","ArchX86_64")</div>

<div> ,("target word size","8")</div><div> ,("target has GNU nonexec stack","True")</div><div> ,("target has .ident directive","True")</div><div> ,("target has subsections via symbols","False")</div>

<div> ,("LLVM llc command","llc")</div><div> ,("LLVM opt command","opt")</div><div> ,("Project version","7.6.3")</div><div> ,("Booter version","7.6.3")</div>

<div> ,("Stage","2")</div><div> ,("Build platform","x86_64-unknown-linux")</div><div> ,("Host platform","x86_64-unknown-linux")</div><div> ,("Target platform","x86_64-unknown-linux")</div>

<div> ,("Have interpreter","YES")</div><div> ,("Object splitting supported","YES")</div><div> ,("Have native code generator","YES")</div><div> ,("Support SMP","YES")</div>

<div> ,("Unregisterised","NO")</div><div> ,("Tables next to code","YES")</div><div> ,("RTS ways","l debug  thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn thr_debug_dyn thr_debug_p")</div>

<div> ,("Leading underscore","NO")</div><div> ,("Debug on","False")</div><div> ,("LibDir","/usr/lib/ghc")</div><div> ,("Global Package DB","/usr/lib/ghc/package.conf.d")</div>

<div> ,("Gcc Linker flags","[\"-Wl,--hash-size=31\",\"-Wl,--reduce-memory-overheads\"]")</div><div> ,("Ld Linker flags","[\"--hash-size=31\",\"--reduce-memory-overheads\"]")</div>

<div> ]</div></div><div><br></div><div><br></div><div>TARGET</div><div>=======</div><div><br></div><div><div> [("Project name","The Glorious Glasgow Haskell Compilation System")</div><div> ,("GCC extra via C opts"," -fwrapv")</div>

<div> ,("C compiler command","arm-poky-linux-gnueabi-gcc")</div><div> ,("C compiler flags"," -fno-stack-protector")</div><div> ,("C compiler link flags","")</div>

<div> ,("ld command","arm-poky-linux-gnueabi-ld")</div><div> ,("ld flags","")</div><div> ,("ld supports compact unwind","YES")</div><div> ,("ld supports build-id","YES")</div>

<div> ,("ld supports filelist","NO")</div><div> ,("ld is GNU ld","YES")</div><div> ,("ar command","/usr/bin/ar")</div><div> ,("ar flags","q")</div>

<div> ,("ar supports at file","YES")</div><div> ,("touch command","touch")</div><div> ,("dllwrap command","/bin/false")</div><div> ,("windres command","/bin/false")</div>

<div> ,("libtool command","libtool")</div><div> ,("perl command","/usr/bin/perl")</div><div> ,("target os","OSLinux")</div><div> ,("target arch","ArchARM {armISA = ARMv5, armISAExt = [], armABI = HARD}")</div>

<div> ,("target word size","4")</div><div> ,("target has GNU nonexec stack","False")</div><div> ,("target has .ident directive","True")</div><div> ,("target has subsections via symbols","False")</div>

<div> ,("Unregisterised","NO")</div><div> ,("LLVM llc command","llc")</div><div> ,("LLVM opt command","opt")</div><div> ,("Project version","7.8.2")</div>

<div> ,("Booter version","7.6.3")</div><div> ,("Stage","1")</div><div> ,("Build platform","x86_64-unknown-linux")</div><div> ,("Host platform","x86_64-unknown-linux")</div>

<div> ,("Target platform","arm-unknown-linux")</div><div> ,("Have interpreter","YES")</div><div> ,("Object splitting supported","NO")</div><div> ,("Have native code generator","NO")</div>

<div> ,("Support SMP","YES")</div><div> ,("Tables next to code","YES")</div><div> ,("RTS ways","l debug thr thr_debug thr_l  ")</div><div> ,("Support dynamic-too","YES")</div>

<div> ,("Support parallel --make","YES")</div><div> ,("Dynamic by default","NO")</div><div> ,("GHC Dynamic","NO")</div><div> ,("Leading underscore","NO")</div>

<div> ,("Debug on","False")</div><div> ,("LibDir","/usr/local/lib/arm-unknown-linux-gnueabi-ghc-7.8.2")</div><div> ,("Global Package DB","/usr/local/lib/arm-unknown-linux-gnueabi-ghc-7.8.2/package.conf.d")</div>

<div> ]</div></div><div><div class="h5"><div><br></div><div><br></div><div><br></div><br><div><div>On Jul 7, 2014, at 10:42 PM, Carter Schonwald <<a href="mailto:carter.schonwald@gmail.com" target="_blank">carter.schonwald@gmail.com</a>> wrote:</div>

<br><blockquote type="cite"><div dir="ltr">could you share the output of ghc --info?</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jul 8, 2014 at 12:10 AM, Michael Jones <span dir="ltr"><<a href="mailto:mike@proclivis.com" target="_blank">mike@proclivis.com</a>></span> wrote:<br>



<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>




<br>
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.<br>
<br>
Some details:<br>
<br>
The application:<br>
<br>
main = do<br>
    putStrLn "Haskell start"<br>
<br>
<br>
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.<br>
<br>
I compile my app as follows:<br>
<br>
arm-unknown-linux-gnueabi-ghc -debug -static Main.hs<br>
<br>
Using -threaded does not fix the problem.<br>
<br>
Let me compare debug data from a run on my HOST, with a run on my TARGET. First, a run from my HOST:<br>
<br>
created capset 0 of type 2<br>
created capset 1 of type 3<br>
cap 0: initialised<br>
assigned cap 0 to capset 0<br>
assigned cap 0 to capset 1<br>
cap 0: created thread 1<br>
cap 0: running thread 1 (ThreadRunGHC)<br>
cap 0: thread 1 stopped (suspended while making a foreign call)<br>
cap 0: running thread 1 (ThreadRunGHC)<br>
cap 0: thread 1 stopped (finished)<br>
cap 0: created thread 2<br>
cap 0: running thread 2 (ThreadRunGHC)<br>
cap 0: thread 2 stopped (finished)<br>
cap 0: starting GC<br>
cap 0: GC working<br>
cap 0: GC idle<br>
cap 0: GC done<br>
cap 0: GC idle<br>
cap 0: GC done<br>
cap 0: GC idle<br>
cap 0: GC done<br>
cap 0: GC idle<br>
cap 0: GC done<br>
cap 0: all caps stopped for GC<br>
cap 0: finished GC<br>
removed cap 0 from capset 0<br>
removed cap 0 from capset 1<br>
cap 0: shutting down<br>
deleted capset 0<br>
deleted capset 1<br>
<br>
And, it prints properly. So this is my referenced for what it should do on the TARGET.<br>
<br>
When I run on my TARGET, I get:<br>
<br>
created capset 0 of type 2<br>
created capset 1 of type 3<br>
cap 0: initialised<br>
assigned cap 0 to capset 0<br>
assigned cap 0 to capset 1<br>
cap 0: created thread 1<br>
cap 0: running thread 1 (ThreadRunGHC)<br>
cap 0: thread 1 stopped (yielding)<br>
cap 0: running thread 1 (ThreadRunGHC)<br>
cap 0: thread 1 stopped (yielding)<br>
cap 0: running thread 1 (ThreadRunGHC)<br>
cap 0: thread 1 stopped (yielding)<br>
cap 0: running thread 1 (ThreadRunGHC)<br>
cap 0: thread 1 stopped (yielding)<br>
cap 0: running thread 1 (ThreadRunGHC)<br>
cap 0: thread 1 stopped (yielding)<br>
cap 0: running thread 1 (ThreadRunGHC)<br>
cap 0: thread 1 stopped (yielding)<br>
cap 0: running thread 1 (ThreadRunGHC)<br>
cap 0: thread 1 stopped (stack overflow)<br>
cap 0: running thread 1 (ThreadRunGHC)<br>
cap 0: thread 1 stopped (stack overflow)<br>
cap 0: running thread 1 (ThreadRunGHC)<br>
cap 0: thread 1 stopped (stack overflow)<br>
cap 0: running thread 1 (ThreadRunGHC)<br>
cap 0: thread 1 stopped (yielding)<br>
cap 0: running thread 1 (ThreadRunGHC)<br>
cap 0: thread 1 stopped (stack overflow)<br>
cap 0: running thread 1 (ThreadRunGHC)<br>
cap 0: thread 1 stopped (stack overflow)<br>
cap 0: running thread 1 (ThreadRunGHC)<br>
cap 0: thread 1 stopped (stack overflow)<br>
cap 0: running thread 1 (ThreadRunGHC)<br>
cap 0: thread 1 stopped (yielding)<br>
cap 0: running thread 1 (ThreadRunGHC)<br>
cap 0: thread 1 stopped (stack overflow)<br>
cap 0: running thread 1 (ThreadRunGHC)<br>
cap 0: thread 1 stopped (heap overflow)<br>
cap 0: starting GC<br>
cap 0: GC working<br>
cap 0: GC idle<br>
cap 0: GC done<br>
cap 0: GC idle<br>
cap 0: GC done<br>
cap 0: GC idle<br>
cap 0: GC done<br>
cap 0: all caps stopped for GC<br>
cap 0: finished GC<br>
cap 0: running thread 1 (ThreadRunGHC)<br>
cap 0: thread 1 stopped (yielding)<br>
cap 0: running thread 1 (ThreadRunGHC)<br>
cap 0: thread 1 stopped (stack overflow)<br>
...<br>
<br>
And the debug data goes on forever, just as debugging assembly demonstrated an infinite loop.<br>
<br>
Clearly, the following does not occur:<br>
<br>
cap 0: thread 1 stopped (suspended while making a foreign call)<br>
<br>
And there are overflows.<br>
<br>
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.<br>




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




<br>
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.<br>
<br>
So I think I need one of the following:<br>
<br>
- A solution from someone that has seen this before, perhaps on the iPhone<br>
- How to enable more debug logging<br>
- Where in the source code to add debug statements to narrow down the problem<br>
<br>
Thanks for any help you can give.<br>
<br>
Mike<br>
<br>
<br>
_______________________________________________<br>
Glasgow-haskell-users mailing list<br>
<a href="mailto:Glasgow-haskell-users@haskell.org" target="_blank">Glasgow-haskell-users@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/glasgow-haskell-users" target="_blank">http://www.haskell.org/mailman/listinfo/glasgow-haskell-users</a><br>
</blockquote></div><br></div>
</blockquote></div><br></div></div></div></blockquote></div><br></div>
</div></blockquote></body></html>