Re: Cross compiling for Cortex A9

Ben, I ran into a snag trying to use the options you suggested. First, I was not sure where to use the flags, so I pasted a piece of my build.mk. You can correct it if I have it wrong. I also get a compile error that I pasted after the build.mk text. I have not made any changes except in aclocal.m4 so that my configure can recognize the target. It can’t figure out the tools, so I add options for all of them. The tools are for the target. That was my interpretation of the wiki. It finds the host tools on its own. add eabi support in aclocal.m4... autoreconf ./configure --target=arm-linux-gnueabi --with-gcc=arm-poky-linux-gnueabi-gcc --with-ld=arm-poky-linux-gnueabi-ld --with-nm=arm-poky-linux-gnueabi-nm --with-ar=arm-poky-linux-gnueabi-ar --with-ranlib=arm-poky-linux-gnueabi-ranlib # -------- A Fast build configured for cross-compilation ---------------------- ifeq "$(BuildFlavour)" "quick-cross" SRC_HC_OPTS = -H64m -O0 -auto-all -caf-all -prof GhcStage1HcOpts = -O -fllvm -auto-all -caf-all -prof GhcStage2HcOpts = -O0 -fllvm GhcLibHcOpts = -O -fllvm -auto-all -caf-all -prof SplitObjs = NO HADDOCK_DOCS = NO BUILD_DOCBOOK_HTML = NO BUILD_DOCBOOK_PS = NO BUILD_DOCBOOK_PDF = NO INTEGER_LIBRARY = integer-simple Stage1Only = YES DYNAMIC_BY_DEFAULT = NO DYNAMIC_GHC_PROGRAMS = NO endif echo "compiler_stage1_depfile_haskell_EXISTS = YES" >> compiler/stage1/build/.depend-v.haskell.tmp for dir in compiler/stage1/build/./ compiler/stage1/build/CodeGen/ compiler/stage1/build/CodeGen/Platform/ compiler/stage1/build/Hoopl/ compiler/stage1/build/Llvm/ compiler/stage1/build/LlvmCodeGen/ compiler/stage1/build/PPC/ compiler/stage1/build/RegAlloc/ compiler/stage1/build/RegAlloc/Graph/ compiler/stage1/build/RegAlloc/Linear/ compiler/stage1/build/RegAlloc/Linear/PPC/ compiler/stage1/build/RegAlloc/Linear/SPARC/ compiler/stage1/build/RegAlloc/Linear/X86/ compiler/stage1/build/RegAlloc/Linear/X86_64/ compiler/stage1/build/SPARC/ compiler/stage1/build/SPARC/CodeGen/ compiler/stage1/build/Vectorise/ compiler/stage1/build/Vectorise/Builtins/ compiler/stage1/build/Vectorise/Generic/ compiler/stage1/build/Vectorise/Monad/ compiler/stage1/build/Vectorise/Type/ compiler/stage1/build/Vectorise/Utils/ compiler/stage1/build/X86/; do if test ! -d $dir; then mkdir -p $dir; fi done grep -v ' : [a-zA-Z]:/' compiler/stage1/build/.depend-v.haskell.tmp > compiler/stage1/build/.depend-v.haskell.tmp2 sed -e '/hs$/ p' -e '/hs$/ s/o /hi /g' -e '/hs$/ s/:/ : %hi: %o /' -e '/hs$/ s/^/$(eval $(call hi-rule,/' -e '/hs$/ s/$/))/' -e '/hs-boot$/ p' -e '/hs-boot$/ s/o-boot /hi-boot /g' -e '/hs-boot$/ s/:/ : %hi-boot: %o-boot /' -e '/hs-boot$/ s/^/$(eval $(call hi-rule,/' -e '/hs-boot$/ s/$/))/' compiler/stage1/build/.depend-v.haskell.tmp2 > compiler/stage1/build/.depend-v.haskell utils/ghc-pkg/ghc.mk:46: warning: overriding commands for target `install_utils/ghc-pkg_dist_wrapper' utils/ghc-pkg/ghc.mk:37: warning: ignoring old commands for target `install_utils/ghc-pkg_dist_wrapper' make[1]: *** No rule to make target `libraries/terminfo/dist-boot/build/System/Console/Terminfo.p_hi', needed by `utils/ghc-pkg/dist/build/Main.o'. Stop. On Jul 9, 2014, at 2:27 PM, Ben Gamari wrote:

Michael Jones writes:

...

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.

Sorry for the delay, almost overlooked this one!

...

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.

Hmmm, very peculiar. I would probably begin by compiling with `-auto-all -caf-all -prof` and run the resulting executable with `+RTS -xc`. SIGINT the process after a second or so and see what the backtrace looks like.

While worth trying, this probably won't help too much as your problem is likely RTS-related. You might try stracing the executable and see if it is ever even trying a syscall.

Unfortunately, I doubt it is as the program appears to be hitting heap and stack overflows. This is quite perplexing. I'm going to try to reproduce the issue on my end.

Cheers,

- Ben