Building on android - compiled program segfaults

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Building on android - compiled program segfaults

Nathan Hüsken
Hi,

I was succesfull in building ghc (pulled from git) to compile for
arm-linux-androideabi!

Now using "inplace/bin/ghc-stage1 -dcore-lint -debug" I compiler this
Main.hs:

main = putStrLn "Hello, World"

I get an executable, which I can run on my android device. Unfortantly
it segfaults.

Running it with ./Main +RTS -DS gives:

cap 0: initialised

Now I am trying to debug this in gdb. When I try to display the stack
(which should be in r13 on arm of I understand correctly, I get);

(gdb) p8 $r13
0xbef00a74: 0x0
0xbef00a70: 0x0
0xbef00a6c: 0x3c2e74
0xbef00a68: 0x530350
0xbef00a64: 0x0
0xbef00a60: 0x0
0xbef00a5c: 0x0
0xbef00a58: 0x0

And now I am clueless. So I tried the good old printf debugging in the
rts. Using this, I see that it gets before the call to
scheduleWaitThread in the function rts_evalLazyIO (in RtsAPI.c).

But when I put a printf in the beginning of scheduleWaitThread (in
Schedule.c) it is not shown.

What else can I do to find out more?
Thanks!
Nathan


Reply | Threaded
Open this post in threaded view
|

Building on android - compiled program segfaults

Simon Marlow-7
On 11/01/13 11:36, Nathan H?sken wrote:

> Hi,
>
> I was succesfull in building ghc (pulled from git) to compile for
> arm-linux-androideabi!
>
> Now using "inplace/bin/ghc-stage1 -dcore-lint -debug" I compiler this
> Main.hs:
>
> main = putStrLn "Hello, World"
>
> I get an executable, which I can run on my android device. Unfortantly
> it segfaults.
>
> Running it with ./Main +RTS -DS gives:
>
> cap 0: initialised
>
> Now I am trying to debug this in gdb. When I try to display the stack
> (which should be in r13 on arm of I understand correctly, I get);

First establish whether the crash is in C or Haskell: what does 'bt'
tell you in gdb?

Cheers,
        Simon


> (gdb) p8 $r13
> 0xbef00a74: 0x0
> 0xbef00a70: 0x0
> 0xbef00a6c: 0x3c2e74
> 0xbef00a68: 0x530350
> 0xbef00a64: 0x0
> 0xbef00a60: 0x0
> 0xbef00a5c: 0x0
> 0xbef00a58: 0x0
>
> And now I am clueless. So I tried the good old printf debugging in the
> rts. Using this, I see that it gets before the call to
> scheduleWaitThread in the function rts_evalLazyIO (in RtsAPI.c).
>
> But when I put a printf in the beginning of scheduleWaitThread (in
> Schedule.c) it is not shown.
>
> What else can I do to find out more?
> Thanks!
> Nathan
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>



Reply | Threaded
Open this post in threaded view
|

Building on android - compiled program segfaults

Ian Lynagh-2
In reply to this post by Nathan Hüsken
On Fri, Jan 11, 2013 at 12:36:22PM +0100, Nathan H?sken wrote:
>
> And now I am clueless. So I tried the good old printf debugging in the
> rts. Using this, I see that it gets before the call to
> scheduleWaitThread in the function rts_evalLazyIO (in RtsAPI.c).
>
> But when I put a printf in the beginning of scheduleWaitThread (in
> Schedule.c) it is not shown.
>
> What else can I do to find out more?

Sounds like it would be useful to set a breakpoint on rts_evalLazyIO,
disassemble, then "si" through the call to scheduleWaitThread to see
what's happening. "info register someregistername" will tell you what's
in someregistername.


Thanks
Ian



Reply | Threaded
Open this post in threaded view
|

Building on android - compiled program segfaults

Nathan Hüsken
In reply to this post by Simon Marlow-7
I just find out how to get in usefull backtrace with android ndk
(unfortantly I am also new to the ndk).

Now I get:
Program received signal SIGSEGV, Segmentation fault.
0x003f05a8 in stg_returnToStackTop ()
(gdb) bt
#0  0x003f05a8 in stg_returnToStackTop ()
#1  0x003c2e74 in schedule (initialCapability=0x3f059c, task=0x530350)
    at rts/Schedule.c:463
#2  0x003c2e74 in schedule (initialCapability=0x530340, task=0x400a42f0)
    at rts/Schedule.c:463
#3  0x003c4c50 in scheduleWaitThread (tso=0x401033c0, ret=0x0,
pcap=0xbe89ab6c)
    at rts/Schedule.c:2345
#4  0x00408544 in rts_evalLazyIO (cap=0xbe89ab6c, p=0x50a020, ret=0x0)
    at rts/RtsAPI.c:499
#5  0x003c08c8 in real_main () at rts/RtsMain.c:68
#6  0x003c0a54 in hs_main (argc=1, argv=0xbe89abf4, main_closure=0x50a020,
    rts_config=...) at rts/RtsMain.c:123
#7  0x0000a23c in main ()

stg_returnToStackTop is defined in rts/StgStartup.cmm (a c-- file).

I would guess that

jump %ENTRY_CODE(Sp(0)) [];

could be the problem. Since p8 $r13 gives me

0xbef00a74:    0x0
(...)

Sp(0) would be 0x0, correct?

On 01/11/2013 02:16 PM, Simon Marlow wrote:

> On 11/01/13 11:36, Nathan H?sken wrote:
>> Hi,
>>
>> I was succesfull in building ghc (pulled from git) to compile for
>> arm-linux-androideabi!
>>
>> Now using "inplace/bin/ghc-stage1 -dcore-lint -debug" I compiler this
>> Main.hs:
>>
>> main = putStrLn "Hello, World"
>>
>> I get an executable, which I can run on my android device. Unfortantly
>> it segfaults.
>>
>> Running it with ./Main +RTS -DS gives:
>>
>> cap 0: initialised
>>
>> Now I am trying to debug this in gdb. When I try to display the stack
>> (which should be in r13 on arm of I understand correctly, I get);
>
> First establish whether the crash is in C or Haskell: what does 'bt'
> tell you in gdb?
>
> Cheers,
>     Simon
>
>
>> (gdb) p8 $r13
>> 0xbef00a74:    0x0
>> 0xbef00a70:    0x0
>> 0xbef00a6c:    0x3c2e74
>> 0xbef00a68:    0x530350
>> 0xbef00a64:    0x0
>> 0xbef00a60:    0x0
>> 0xbef00a5c:    0x0
>> 0xbef00a58:    0x0
>>
>> And now I am clueless. So I tried the good old printf debugging in the
>> rts. Using this, I see that it gets before the call to
>> scheduleWaitThread in the function rts_evalLazyIO (in RtsAPI.c).
>>
>> But when I put a printf in the beginning of scheduleWaitThread (in
>> Schedule.c) it is not shown.
>>
>> What else can I do to find out more?
>> Thanks!
>> Nathan
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>



Reply | Threaded
Open this post in threaded view
|

Building on android - compiled program segfaults

Simon Marlow-7
On 11/01/13 13:47, Nathan H?sken wrote:

> I just find out how to get in usefull backtrace with android ndk
> (unfortantly I am also new to the ndk).
>
> Now I get:
> Program received signal SIGSEGV, Segmentation fault.
> 0x003f05a8 in stg_returnToStackTop ()
> (gdb) bt
> #0  0x003f05a8 in stg_returnToStackTop ()
> #1  0x003c2e74 in schedule (initialCapability=0x3f059c, task=0x530350)
>      at rts/Schedule.c:463
> #2  0x003c2e74 in schedule (initialCapability=0x530340, task=0x400a42f0)
>      at rts/Schedule.c:463
> #3  0x003c4c50 in scheduleWaitThread (tso=0x401033c0, ret=0x0,
> pcap=0xbe89ab6c)
>      at rts/Schedule.c:2345
> #4  0x00408544 in rts_evalLazyIO (cap=0xbe89ab6c, p=0x50a020, ret=0x0)
>      at rts/RtsAPI.c:499
> #5  0x003c08c8 in real_main () at rts/RtsMain.c:68
> #6  0x003c0a54 in hs_main (argc=1, argv=0xbe89abf4, main_closure=0x50a020,
>      rts_config=...) at rts/RtsMain.c:123
> #7  0x0000a23c in main ()
>
> stg_returnToStackTop is defined in rts/StgStartup.cmm (a c-- file).
>
> I would guess that
>
> jump %ENTRY_CODE(Sp(0)) [];
>
> could be the problem. Since p8 $r13 gives me
>
> 0xbef00a74:    0x0
> (...)
>
> Sp(0) would be 0x0, correct?

It's dying pretty quickly after entering Haskell: stg_returnToStackTop
is the first bit of code to execute on the Haskell side.  You should be
able to disassemble that function and see whether it makes sense, and/or
step through it to see where things go wrong.  It does look like $r13 is
not pointing to stack data for some reason.

Cheers,
        Simon


> On 01/11/2013 02:16 PM, Simon Marlow wrote:
>> On 11/01/13 11:36, Nathan H?sken wrote:
>>> Hi,
>>>
>>> I was succesfull in building ghc (pulled from git) to compile for
>>> arm-linux-androideabi!
>>>
>>> Now using "inplace/bin/ghc-stage1 -dcore-lint -debug" I compiler this
>>> Main.hs:
>>>
>>> main = putStrLn "Hello, World"
>>>
>>> I get an executable, which I can run on my android device. Unfortantly
>>> it segfaults.
>>>
>>> Running it with ./Main +RTS -DS gives:
>>>
>>> cap 0: initialised
>>>
>>> Now I am trying to debug this in gdb. When I try to display the stack
>>> (which should be in r13 on arm of I understand correctly, I get);
>>
>> First establish whether the crash is in C or Haskell: what does 'bt'
>> tell you in gdb?
>>
>> Cheers,
>>      Simon
>>
>>
>>> (gdb) p8 $r13
>>> 0xbef00a74:    0x0
>>> 0xbef00a70:    0x0
>>> 0xbef00a6c:    0x3c2e74
>>> 0xbef00a68:    0x530350
>>> 0xbef00a64:    0x0
>>> 0xbef00a60:    0x0
>>> 0xbef00a5c:    0x0
>>> 0xbef00a58:    0x0
>>>
>>> And now I am clueless. So I tried the good old printf debugging in the
>>> rts. Using this, I see that it gets before the call to
>>> scheduleWaitThread in the function rts_evalLazyIO (in RtsAPI.c).
>>>
>>> But when I put a printf in the beginning of scheduleWaitThread (in
>>> Schedule.c) it is not shown.
>>>
>>> What else can I do to find out more?
>>> Thanks!
>>> Nathan
>>>
>>> _______________________________________________
>>> ghc-devs mailing list
>>> ghc-devs at haskell.org
>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>>
>>
>



Reply | Threaded
Open this post in threaded view
|

Building on android - compiled program segfaults

Nathan Hüsken
The disassembly at the moment of segfault looks like this:

Dump of assembler code for function stg_returnToStackTop:
   0x003f059c <+0>: push {r4, lr}
   0x003f05a0 <+4>: sub sp, sp, #16
   0x003f05a4 <+8>: ldr r1, [r0, #140] ; 0x8c
=> 0x003f05a8 <+12>: ldr r12, [r1, #12]
   0x003f05ac <+16>: ldr r1, [r12, #12]
   0x003f05b0 <+20>: mov r2, #0
   0x003f05b4 <+24>: str r2, [r0, #156] ; 0x9c
   0x003f05b8 <+28>: ldr r4, [r0, #148] ; 0x94
   0x003f05bc <+32>: ldm r4, {r2, lr}
   0x003f05c0 <+36>: ldr r4, [r4, #28]
   0x003f05c4 <+40>: add r2, r2, r4, lsl #12
   0x003f05c8 <+44>: sub r2, r2, #1
   0x003f05cc <+48>: str r2, [r0, #132] ; 0x84
   0x003f05d0 <+52>: subs r2, lr, #4

If I see this correctly, r12 is loaded with the value at ($r1+12)
The value of $r1 is:

r1             0xe24dd010 -498216944

which seems way out of bounds (if I look at the values of the other
registers).
The value of r1 comes from ($r0+140) in the instruction above.
But where is this value written?

I am sorry that I am so helpless. Some Idea where I could go from here?

On 01/11/2013 03:36 PM, Simon Marlow wrote:

> On 11/01/13 13:47, Nathan H?sken wrote:
>> I just find out how to get in usefull backtrace with android ndk
>> (unfortantly I am also new to the ndk).
>>
>> Now I get:
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x003f05a8 in stg_returnToStackTop ()
>> (gdb) bt
>> #0  0x003f05a8 in stg_returnToStackTop ()
>> #1  0x003c2e74 in schedule (initialCapability=0x3f059c, task=0x530350)
>>      at rts/Schedule.c:463
>> #2  0x003c2e74 in schedule (initialCapability=0x530340, task=0x400a42f0)
>>      at rts/Schedule.c:463
>> #3  0x003c4c50 in scheduleWaitThread (tso=0x401033c0, ret=0x0,
>> pcap=0xbe89ab6c)
>>      at rts/Schedule.c:2345
>> #4  0x00408544 in rts_evalLazyIO (cap=0xbe89ab6c, p=0x50a020, ret=0x0)
>>      at rts/RtsAPI.c:499
>> #5  0x003c08c8 in real_main () at rts/RtsMain.c:68
>> #6  0x003c0a54 in hs_main (argc=1, argv=0xbe89abf4,
>> main_closure=0x50a020,
>>      rts_config=...) at rts/RtsMain.c:123
>> #7  0x0000a23c in main ()
>>
>> stg_returnToStackTop is defined in rts/StgStartup.cmm (a c-- file).
>>
>> I would guess that
>>
>> jump %ENTRY_CODE(Sp(0)) [];
>>
>> could be the problem. Since p8 $r13 gives me
>>
>> 0xbef00a74:    0x0
>> (...)
>>
>> Sp(0) would be 0x0, correct?
>
> It's dying pretty quickly after entering Haskell: stg_returnToStackTop
> is the first bit of code to execute on the Haskell side.  You should be
> able to disassemble that function and see whether it makes sense, and/or
> step through it to see where things go wrong.  It does look like $r13 is
> not pointing to stack data for some reason.
>
> Cheers,
>     Simon
>
>
>> On 01/11/2013 02:16 PM, Simon Marlow wrote:
>>> On 11/01/13 11:36, Nathan H?sken wrote:
>>>> Hi,
>>>>
>>>> I was succesfull in building ghc (pulled from git) to compile for
>>>> arm-linux-androideabi!
>>>>
>>>> Now using "inplace/bin/ghc-stage1 -dcore-lint -debug" I compiler this
>>>> Main.hs:
>>>>
>>>> main = putStrLn "Hello, World"
>>>>
>>>> I get an executable, which I can run on my android device. Unfortantly
>>>> it segfaults.
>>>>
>>>> Running it with ./Main +RTS -DS gives:
>>>>
>>>> cap 0: initialised
>>>>
>>>> Now I am trying to debug this in gdb. When I try to display the stack
>>>> (which should be in r13 on arm of I understand correctly, I get);
>>>
>>> First establish whether the crash is in C or Haskell: what does 'bt'
>>> tell you in gdb?
>>>
>>> Cheers,
>>>      Simon
>>>
>>>
>>>> (gdb) p8 $r13
>>>> 0xbef00a74:    0x0
>>>> 0xbef00a70:    0x0
>>>> 0xbef00a6c:    0x3c2e74
>>>> 0xbef00a68:    0x530350
>>>> 0xbef00a64:    0x0
>>>> 0xbef00a60:    0x0
>>>> 0xbef00a5c:    0x0
>>>> 0xbef00a58:    0x0
>>>>
>>>> And now I am clueless. So I tried the good old printf debugging in the
>>>> rts. Using this, I see that it gets before the call to
>>>> scheduleWaitThread in the function rts_evalLazyIO (in RtsAPI.c).
>>>>
>>>> But when I put a printf in the beginning of scheduleWaitThread (in
>>>> Schedule.c) it is not shown.
>>>>
>>>> What else can I do to find out more?
>>>> Thanks!
>>>> Nathan
>>>>
>>>> _______________________________________________
>>>> ghc-devs mailing list
>>>> ghc-devs at haskell.org
>>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>>>
>>>
>>
>



Reply | Threaded
Open this post in threaded view
|

Building on android - compiled program segfaults

Nathan Hüsken
In reply to this post by Ian Lynagh-2
Ok, there I was a stupid.
When I flush stdout I see the output of those printfs.
The segfaults happens somehwere else (see the other answers).

On 01/11/2013 02:31 PM, Ian Lynagh wrote:

> On Fri, Jan 11, 2013 at 12:36:22PM +0100, Nathan H?sken wrote:
>>
>> And now I am clueless. So I tried the good old printf debugging in the
>> rts. Using this, I see that it gets before the call to
>> scheduleWaitThread in the function rts_evalLazyIO (in RtsAPI.c).
>>
>> But when I put a printf in the beginning of scheduleWaitThread (in
>> Schedule.c) it is not shown.
>>
>> What else can I do to find out more?
>
> Sounds like it would be useful to set a breakpoint on rts_evalLazyIO,
> disassemble, then "si" through the call to scheduleWaitThread to see
> what's happening. "info register someregistername" will tell you what's
> in someregistername.
>
>
> Thanks
> Ian
>



Reply | Threaded
Open this post in threaded view
|

Building on android - compiled program segfaults

Nathan Hüsken
In reply to this post by Nathan Hüsken
Ok, $r0 + 140 is loaded into $r1.
The value at the address ($r0+140 = 0x3F06A0) at the moment of crash is
the same as at the moment main is entered. And a watch on this address
reveals, that it is not touched.


On 01/11/2013 04:09 PM, Nathan H?sken wrote:

> The disassembly at the moment of segfault looks like this:
>
> Dump of assembler code for function stg_returnToStackTop:
>    0x003f059c <+0>: push {r4, lr}
>    0x003f05a0 <+4>: sub sp, sp, #16
>    0x003f05a4 <+8>: ldr r1, [r0, #140] ; 0x8c
> => 0x003f05a8 <+12>: ldr r12, [r1, #12]
>    0x003f05ac <+16>: ldr r1, [r12, #12]
>    0x003f05b0 <+20>: mov r2, #0
>    0x003f05b4 <+24>: str r2, [r0, #156] ; 0x9c
>    0x003f05b8 <+28>: ldr r4, [r0, #148] ; 0x94
>    0x003f05bc <+32>: ldm r4, {r2, lr}
>    0x003f05c0 <+36>: ldr r4, [r4, #28]
>    0x003f05c4 <+40>: add r2, r2, r4, lsl #12
>    0x003f05c8 <+44>: sub r2, r2, #1
>    0x003f05cc <+48>: str r2, [r0, #132] ; 0x84
>    0x003f05d0 <+52>: subs r2, lr, #4
>
> If I see this correctly, r12 is loaded with the value at ($r1+12)
> The value of $r1 is:
>
> r1             0xe24dd010 -498216944
>
> which seems way out of bounds (if I look at the values of the other
> registers).
> The value of r1 comes from ($r0+140) in the instruction above.
> But where is this value written?
>
> I am sorry that I am so helpless. Some Idea where I could go from here?
>
> On 01/11/2013 03:36 PM, Simon Marlow wrote:
>> On 11/01/13 13:47, Nathan H?sken wrote:
>>> I just find out how to get in usefull backtrace with android ndk
>>> (unfortantly I am also new to the ndk).
>>>
>>> Now I get:
>>> Program received signal SIGSEGV, Segmentation fault.
>>> 0x003f05a8 in stg_returnToStackTop ()
>>> (gdb) bt
>>> #0  0x003f05a8 in stg_returnToStackTop ()
>>> #1  0x003c2e74 in schedule (initialCapability=0x3f059c, task=0x530350)
>>>      at rts/Schedule.c:463
>>> #2  0x003c2e74 in schedule (initialCapability=0x530340, task=0x400a42f0)
>>>      at rts/Schedule.c:463
>>> #3  0x003c4c50 in scheduleWaitThread (tso=0x401033c0, ret=0x0,
>>> pcap=0xbe89ab6c)
>>>      at rts/Schedule.c:2345
>>> #4  0x00408544 in rts_evalLazyIO (cap=0xbe89ab6c, p=0x50a020, ret=0x0)
>>>      at rts/RtsAPI.c:499
>>> #5  0x003c08c8 in real_main () at rts/RtsMain.c:68
>>> #6  0x003c0a54 in hs_main (argc=1, argv=0xbe89abf4,
>>> main_closure=0x50a020,
>>>      rts_config=...) at rts/RtsMain.c:123
>>> #7  0x0000a23c in main ()
>>>
>>> stg_returnToStackTop is defined in rts/StgStartup.cmm (a c-- file).
>>>
>>> I would guess that
>>>
>>> jump %ENTRY_CODE(Sp(0)) [];
>>>
>>> could be the problem. Since p8 $r13 gives me
>>>
>>> 0xbef00a74:    0x0
>>> (...)
>>>
>>> Sp(0) would be 0x0, correct?
>>
>> It's dying pretty quickly after entering Haskell: stg_returnToStackTop
>> is the first bit of code to execute on the Haskell side.  You should be
>> able to disassemble that function and see whether it makes sense, and/or
>> step through it to see where things go wrong.  It does look like $r13 is
>> not pointing to stack data for some reason.
>>
>> Cheers,
>>     Simon
>>
>>
>>> On 01/11/2013 02:16 PM, Simon Marlow wrote:
>>>> On 11/01/13 11:36, Nathan H?sken wrote:
>>>>> Hi,
>>>>>
>>>>> I was succesfull in building ghc (pulled from git) to compile for
>>>>> arm-linux-androideabi!
>>>>>
>>>>> Now using "inplace/bin/ghc-stage1 -dcore-lint -debug" I compiler this
>>>>> Main.hs:
>>>>>
>>>>> main = putStrLn "Hello, World"
>>>>>
>>>>> I get an executable, which I can run on my android device. Unfortantly
>>>>> it segfaults.
>>>>>
>>>>> Running it with ./Main +RTS -DS gives:
>>>>>
>>>>> cap 0: initialised
>>>>>
>>>>> Now I am trying to debug this in gdb. When I try to display the stack
>>>>> (which should be in r13 on arm of I understand correctly, I get);
>>>>
>>>> First establish whether the crash is in C or Haskell: what does 'bt'
>>>> tell you in gdb?
>>>>
>>>> Cheers,
>>>>      Simon
>>>>
>>>>
>>>>> (gdb) p8 $r13
>>>>> 0xbef00a74:    0x0
>>>>> 0xbef00a70:    0x0
>>>>> 0xbef00a6c:    0x3c2e74
>>>>> 0xbef00a68:    0x530350
>>>>> 0xbef00a64:    0x0
>>>>> 0xbef00a60:    0x0
>>>>> 0xbef00a5c:    0x0
>>>>> 0xbef00a58:    0x0
>>>>>
>>>>> And now I am clueless. So I tried the good old printf debugging in the
>>>>> rts. Using this, I see that it gets before the call to
>>>>> scheduleWaitThread in the function rts_evalLazyIO (in RtsAPI.c).
>>>>>
>>>>> But when I put a printf in the beginning of scheduleWaitThread (in
>>>>> Schedule.c) it is not shown.
>>>>>
>>>>> What else can I do to find out more?
>>>>> Thanks!
>>>>> Nathan
>>>>>
>>>>> _______________________________________________
>>>>> ghc-devs mailing list
>>>>> ghc-devs at haskell.org
>>>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>>>>
>>>>
>>>
>>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>



Reply | Threaded
Open this post in threaded view
|

Building on android - compiled program segfaults

Nathan Hüsken
In reply to this post by Nathan Hüsken
There is some more success :).
When I do an unregisterised build, it works without segfault.

On 01/13/2013 11:16 AM, Bernhard Urban wrote:
> Hi Nathan,
>
> On Fri, Jan 11, 2013 at 12:36 PM, Nathan H?sken
> <nathan.huesken at posteo.de> wrote:
>> I was succesfull in building ghc (pulled from git) to compile for
>> arm-linux-androideabi!
>
> Great news!
> Can you describe how you managed to build it and which environment you use?

I am on ubuntu 64  bit.
I am planing to share the information in a blog post, but I will wait if
I (or someone else) gets the registerised build to work.

I made a short writedown of the steps it took here:
https://github.com/RudolfVonKrugstein/jshaskell-blog/blob/master/android_ghc/android_ghc.md

Regards,
Nathan


Reply | Threaded
Open this post in threaded view
|

Building on android - compiled program segfaults

Nathan Hüsken
In reply to this post by Nathan Hüsken
Mmh, that does not seem to work.

(gdb) strace
warning: Couldn't determine the static tracepoint marker to probe
Static tracepoint 1 at 0x3f0588

On 01/13/2013 12:56 PM, Conrad Parker wrote:

> On 11 January 2013 19:36, Nathan H?sken <nathan.huesken at posteo.de> wrote:
>> Hi,
>>
>> I was succesfull in building ghc (pulled from git) to compile for
>> arm-linux-androideabi!
>>
>> Now using "inplace/bin/ghc-stage1 -dcore-lint -debug" I compiler this
>> Main.hs:
>>
>> main = putStrLn "Hello, World"
>>
>> I get an executable, which I can run on my android device. Unfortantly
>> it segfaults.
>>
>> Running it with ./Main +RTS -DS gives:
>>
>> cap 0: initialised
>>
>> Now I am trying to debug this in gdb. When I try to display the stack
>> (which should be in r13 on arm of I understand correctly, I get);
>>
>> (gdb) p8 $r13
>> 0xbef00a74:     0x0
>> 0xbef00a70:     0x0
>> 0xbef00a6c:     0x3c2e74
>> 0xbef00a68:     0x530350
>> 0xbef00a64:     0x0
>> 0xbef00a60:     0x0
>> 0xbef00a5c:     0x0
>> 0xbef00a58:     0x0
>>
>> And now I am clueless. So I tried the good old printf debugging in the
>> rts. Using this, I see that it gets before the call to
>> scheduleWaitThread in the function rts_evalLazyIO (in RtsAPI.c).
>>
>> But when I put a printf in the beginning of scheduleWaitThread (in
>> Schedule.c) it is not shown.
>>
>> What else can I do to find out more?
>
> can you strace it?
>
> Conrad.
>