That doc says: ...This will usually manifest itself as a failure of dll-split during the build process with internal error: evacuate(static): strange closure type 0.
Which does not happen when I build. Until this is fixed, the newer gold linker will be the only supported linker with GHC on ARM (at least when tables-next-to-code is enabled). GHC now checks 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. And I don't get an error indicating this bug unless it is a warning missed in the massive build output. 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. Mike Sent from my iPad > On Jul 8, 2014, at 12:03 AM, Carter Schonwald <carter.schonw...@gmail.com> > wrote: > > 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
