Cross compiling for Cortex A9
Michael Jones
mike at proclivis.com
Fri Jul 11 11:56:33 UTC 2014
Karel,
Not solved yet, but I did not notice the target problem. It is obvious once pointed out. I’ll try to fix that and try again and report back.
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20140711/92dcb47d/attachment-0001.html>
More information about the Glasgow-haskell-users
mailing list