Cross compiling for Cortex A9

Michael Jones mike at proclivis.com
Tue Aug 5 14:23:48 UTC 2014 

I ran the same program on my dev linux and compared it to see if there were clues.

On my dev box (Ubuntu) here are some snippets of the log (working app)

new task (taskCount: 1)
cap 0: created thread 1
new bound thread (1)
cap 0: schedule()
cap 0: running thread 1 (ThreadRunGHC)

New weak pointer at 0x7f7788704050
stg_ap_0_ret... base:GHC.MVar.MVar(0x7f7788704148)

stg_ap_0_ret... ghc-prim:GHC.Tuple.(,)(0x7f7788704281, 0x7f7788704272)
stg_ap_0_ret... ghc-prim:GHC.Types.:(0x7f7788704421, 0x7f778870440a)

New weak pointer at 0x7f7788706188
stg_ap_0_ret... base:GHC.IO.Handle.Types.FileHandle(0x6d4080, 0x7f77887060b0)

And on the failing embedded target:

new task (taskCount: 1)
cap 0: created thread 1
new bound thread (1)
cap 0: schedule()
cap 0: running thread 1 (ThreadRunGHC)

New weak pointer at 0x76c02038
stg_ap_0_ret... base:GHC.MVar.MVar(0x76c020d4)

stg_ap_0_ret... ghc-prim:GHC.Tuple.(,)(0x76c021a9, 0x76c0219a)
cap 0: thread 1 stopped (yielding)
cap 0: running thread 1 (ThreadRunGHC)

stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c023d1, 0x76c023be)

stg_ap_0_ret... ghc-prim:GHC.Tuple.(,)(0x76c029a1, 0x76c02992)

stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c05068)
stg_ap_0_ret... ghc-prim:GHC.Types.[]()
stg_ap_v_ret... IND_STATIC(0x76c0360c)
stg_ap_v_ret... FUN/1(0x59088, CAF, 0x76c02980)

cap 0: thread 1 stopped (stack overflow)

A couple of things are different in the failing target. First, the thread yields, and then is allowed to run, whereas on Ubuntu it just runs to completion. Second, there is a second set of primitive calls:

stg_ap_0_ret... ghc-prim:GHC.Tuple.(,)(0x76c029a1, 0x76c02992)
stg_ap_0_ret... ghc-prim:GHC.Types.[]()
cap 0: thread 1 stopped (stack overflow)

And this is followed by the stack overflow. These two calls are not present when run on Ubuntu.

The original source is:

module Main where
main::IO()
main = putStr "Hello world!”

As a reminder, the difference is:

Working: Standard GHC on Ubuntu
Failing: Cross compiled for Cortex A and run on Wandboard with Yocto Linux

Do these extra two calls give any clues to the cause of the stack flow?

The other thing to note, is the working version eventually gets to various IO calls. These are never reached in the failing version. So it seems to be choking in the type system code before it gets to IO. Is there a test program that could be run that might narrow down the problem?

Mike


On Aug 4, 2014, at 8:23 AM, Michael Jones <mike at proclivis.com> wrote:

> To be complete, there is an old link on compiling for arm, and it recommends this build process:
> 
> $ chmod ugo+rx build-ghc-arm.sh
> Edit build-ghc-arm.sh to fix EOF
> $ ./build-ghc-arm.sh -j4
> $ make test
> $ sudo make install
> $ arm-poky-linux-gnueabi-ghc --info
> 
> This way of building produces the same result as below. So I am guessing that problems that this fixed moons ago no longer exist, or produce different problems that are masked.
> 
> What will help me, not knowing the RTS, is if anyone can recognize the failure pattern and give me some hints where in the code the problem might be. That way I can add some logging specifically related to the problem to get more data, and limit my study of the RTS code to a specific set of files.
> 
> My other thought is if there is some test code that might help reveal the problem. Something that if it runs, and the log is clean, perhaps eliminates possible problems. The RTS is able to write a log via stdio, so that could be exploited to run test code that can log information. But the hello world fails to write to stdio. So perhaps the problem occurs in the start up phase where the thread is created and things go wrong before hello world is executed. This would suggest any test code would have to be run within the RTS itself. Is there some way to enable some ASSERTIONS within RTS that would help narrow down the problem?
> 
> Also, is there any way to compile up something small to run the RTS without any Haskell libraries, etc, so and debug it with a C/C++ debugger? I am able to debug other C/C++ programs on the target device, so if I had a C/C++ program, code, etc, I could run and debug it.
> 
> Mike
> 
> 
> On Aug 2, 2014, at 4:04 PM, Michael Jones <mike at proclivis.com> wrote:
> 
>> Karel,
>> 
>> My configure hack is now limited to two hacks on GHC 7.8.3. The vendor “pokey", and the ARM settings that make the target architecture correct. I also enabled profiling in build.mk. So pretty clean. No compiler options. GHC compiles clean.
>> 
>> I am getting a stack overflow during execution of the hello world applicaiton. I compiled like:
>> 
>> arm-poky-linux-gnueabi-ghc -static -debug -auto-all -caf-all -prof Main.hs
>> 
>> I ran on the target like:
>> 
>> ./Main +RTS -Ds -Di -Db -DS -Dt -Da 2>log
>> 
>> I attached a log. Search for overflow.
>> 
>> 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
>> free block list [0]:
>> free block list [1]:
>> free block list [2]:
>> free block list [3]:
>> free block list [4]:
>> free block list [5]:
>> free block list [6]:
>> group at 0x76c82000, length 126 blocks
>> free block list [7]:
>> free block list [8]:
>> free block list [0]:
>> free block list [1]:
>> free block list [2]:
>> free block list [3]:
>> free block list [4]:
>> free block list [5]:
>> free block list [6]:
>> group at 0x76c82000, length 126 blocks
>> free block list [7]:
>> free block list [8]:
>> free block list [0]:
>> free block list [1]:
>> free block list [2]:
>> free block list [3]:
>> free block list [4]:
>> free block list [5]:
>> free block list [6]:
>> group at 0x76c82000, length 125 blocks
>> free block list [7]:
>> free block list [8]:
>> free block list [0]:
>> free block list [1]:
>> free block list [2]:
>> free block list [3]:
>> free block list [4]:
>> free block list [5]:
>> free block list [6]:
>> group at 0x76c82000, length 124 blocks
>> free block list [7]:
>> free block list [8]:
>> free block list [0]:
>> free block list [1]:
>> free block list [2]:
>> free block list [3]:
>> free block list [4]:
>> free block list [5]:
>> free block list [6]:
>> group at 0x76c82000, length 123 blocks
>> free block list [7]:
>> free block list [8]:
>> free block list [0]:
>> free block list [1]:
>> free block list [2]:
>> free block list [3]:
>> free block list [4]:
>> free block list [5]:
>> free block list [6]:
>> group at 0x76c82000, length 122 blocks
>> free block list [7]:
>> free block list [8]:
>> new task (taskCount: 1)
>> cap 0: created thread 1
>> new bound thread (1)
>> cap 0: schedule()
>> cap 0: running thread 1 (ThreadRunGHC)
>> stg_ap_v_ret... PAP/1(0x5ba25a, 0x5a3670)
>> stg_ap_0_ret... base:GHC.MVar.MVar(0x76c020d4)
>> stg_ap_v_ret... <Main.main>(0xa964, CAF:main)
>> stg_ap_v_ret... PAP/1(0x5bce1a, 0x76c02160)
>> stg_ap_0_ret... ghc-prim:GHC.Tuple.(,)(0x76c021a9, 0x76c0219a)
>> stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c023d1, 0x76c023be)
>> cap 0: thread 1 stopped (yielding)
>> cap 0: running thread 1 (ThreadRunGHC)
>> stg_ap_0_ret... base:GHC.IO.Encoding.Types.TextEncoding(0x5aadd0, 0x76c026c5, 0x76c02665)
>> stg_ap_v_ret... <GHC.IO.Encoding.getForeignEncoding>(0x59458, CAF)
>> stg_ap_0_ret... ghc-prim:GHC.Tuple.(,)(0x76c029a1, 0x76c02992)
>> stg_ap_0_ret... FUN/1(0x59088, CAF, 0x76c02980)
>> stg_ap_v_ret... FUN/1(0x59088, CAF, 0x76c02980)
>> stg_ap_0_ret... base:GHC.IO.Encoding.Types.TextEncoding(0x5aadd0, 0x76c02aa1, 0x76c02a41)
>> stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c023d1, 0x76c02b40)
>> stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c023ad, 0x76c02ba8)
>> stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c02389, 0x76c02c10)
>> stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c02365, 0x76c02c78)
>> stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c02341, 0x76c02ce0)
>> stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c0231d, 0x76c02d48)
>> stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c022f9, 0x76c02db0)
>> stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c022d5, 0x76c02e18)
>> stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c022b1, 0x76c02e80)
>> stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c0228d, 0x76c02ee8)
>> stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c02269, 0x76c02f50)
>> stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c02245, 0x76c02fb8)
>> stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c02221, 0x76c0502c)
>> stg_ap_0_ret... ghc-prim:GHC.Types.:(0x76c021fd, 0x76c05094)
>> stg_ap_0_ret... ghc-prim:GHC.Types.[]()
>> stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c02b14)
>> stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c02b7c)
>> stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c02be4)
>> stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c02c4c)
>> stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c02cb4)
>> stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c02d1c)
>> stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c02d84)
>> stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c02dec)
>> stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c02e54)
>> stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c02ebc)
>> stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c02f24)
>> stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c02f8c)
>> stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c05000)
>> stg_ap_0_ret... THUNK_SELECTOR(0x46ee50, CAF, 0x76c05068)
>> stg_ap_0_ret... ghc-prim:GHC.Types.[]()
>> stg_ap_v_ret... IND_STATIC(0x76c0360c)
>> stg_ap_v_ret... FUN/1(0x59088, CAF, 0x76c02980)
>> stg_ap_v_ret... IND_STATIC(0x76c0360c)
>> stg_ap_v_ret... FUN/1(0x59088, CAF, 0x76c02980)
>> stg_ap_v_ret... IND_STATIC(0x76c0360c)
>> stg_ap_v_ret... FUN/1(0x59088, CAF, 0x76c02980)
>> stg_ap_v_ret... IND_STATIC(0x76c0360c)
>> stg_ap_v_ret... FUN/1(0x59088, CAF, 0x76c02980)
>> stg_ap_v_ret... IND_STATIC(0x76c0360c)
>> stg_ap_v_ret... FUN/1(0x59088, CAF, 0x76c02980)
>> stg_ap_v_ret... IND_STATIC(0x76c0360c)
>> stg_ap_v_ret... FUN/1(0x59088, CAF, 0x76c02980)
>> cap 0: thread 1 stopped (stack overflow)
>> On Aug 2, 2014, at 12:07 PM, Karel Gardas <karel.gardas at centrum.cz> wrote:
>> 
>>> On 08/ 2/14 07:04 AM, Michael Jones wrote:
>>> 
>>>> ,("target arch","ArchARM {armISA = ARMv7, armISAExt = [VFPv3,NEON], armABI = HARD}")
>>>> ,("target word size","4")
>>> 
>>> this looks good, but I hope you got it on clean tree, i.e. without your configure hack...
>>> 
>>> Karel
>> 
>> 
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> 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