Cross compiling for Cortex A9
Michael Jones
mike at proclivis.com
Sat Jul 12 05:27:06 UTC 2014
Karel,
I have failed to figure out how to make this happen:
("target arch", "ArchARM {armISA = ARMv7, armISAExt = [VFPv3,NEON], armABI = HARD}”)
I have added poky to the list of vendors in aclocal.m4 then configured like this:
/configure --target=arm-poky-linux-gnueabi --with-gcc=arm-poky-linux-gnueabi-gcc
But I end up with ARMv5.
I am new to Autotools and the Haskell build system, so I am not sure what controls this. I assume the idea is that the gcc cross-compiler compiles some code that checks for versions when it evaluates stuff like:
AC_COMPILE_IFELSE([
AC_LANG_PROGRAM(
[],
[#if defined(__ARM_ARCH_2__) || \
defined(__ARM_ARCH_3__) || \
defined(__ARM_ARCH_3M__) || \
defined(__ARM_ARCH_4__) || \
defined(__ARM_ARCH_4T__) || \
So I then suspect the compiler needs options like -mcpu=cortex-a9 -mfpu=neon to make the proper version defined, so that the code can check the architecture.
But if all these assumptions are true, it is not clear where to put these options. But that is a big if.
Can you explain or point to a doc that explains how this works? The Haskell Developer Wiki does not get into the details at this level.
Or, if you have tweaked files for the Panda, I can difference them with mine and figure it out.
Thanks,
Mike
On Jul 11, 2014, at 4:35 AM, Karel Gardas <karel.gardas at centrum.cz> wrote:
>
> I'm not sure if this is already solved, but if you cross-compile to A9, why do you use ARMv5 platform OS?
>
> ("target arch","ArchARM {armISA = ARMv5, armISAExt = [], armABI = HARD}")
>
> this looks really strange. armABI HARD, that means FP data in FP regs, still no VFP in armISAExt and even armISA set to ARMv5.
>
> For example on my ubuntu 12.04 I do have:
>
> ("target arch", "ArchARM {armISA = ARMv7, armISAExt = [VFPv3,NEON], armABI = HARD}"),
>
> which is right for pandaboard which is dual Cortex-A9.
>
> So, shortly I really do not know if you do not hit some corner case in LLVM here. I would certainly suggest especially considering your Cortex-A9 target to update your OS to get to what I do have here: ARMv7+VFPv3/NEON+ABI HARD.
>
> BTW: Another issue may be that GHC misconfigures on your platform and they you will need to tell us more about your target OS...
>
> Cheers,
> Karel
>
> On 07/ 8/14 07:51 AM, Michael Jones 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 <mailto: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
>>> <mailto: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
>>> <mailto:Glasgow-haskell-users at haskell.org>
>>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>>
>>>
>>
>>
>>
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users at haskell.org
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
More information about the Glasgow-haskell-users
mailing list