Understand disassemble for segfault on android

[Nathan Hüsken]

Ok, the instruction

ldr	r1, [r0, #140]  <-> tso = CurrentTSO

seems the assume that REG_Base is r0 (140 is the offset of the tso in
StgRegTable, to which the REG_Base register should point).
But according to MachRegs.h on arm architecture, REG_Base should be r4.

Ineed, when I do

p *(unsigned int*)($r4+140)

I get (after converting to hex) is:

0x401033C0

looking at the backtrace:

(...)
#3  0x003c4cb0 in scheduleWaitThread (tso=0x401033c0, ret=0x0,
pcap=0xbe843b6c)
(...)

this is the same address as given to scheduleWaitThread for tso.

So the question is, why is r0 and not r4 used???

Regards,
Nathan

On 01/13/2013 12:10 AM, Nathan Hüsken wrote:
> Hey,
> 
> I am still investigating the segfaults of the exectuable produced by ghc
> to arm-linux-androideabi cross compiler.
> 
> I need help. Can someone tell me if my conclusions are correct?
> 
> The crash happens here:
> 
> 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
> 
> Since it is in the begining of stg_returnToStackTop, it has to be
> LOAD_THREAD_STATE();
> I believe the code for this is produced by loadThreadState:
> 
> loadThreadState dflags tso stack = do
>   catAGraphs [
>         -- tso = CurrentTSO;
>         mkAssign (CmmLocal tso) stgCurrentTSO,
>         -- stack = tso->stackobj;
>         mkAssign (CmmLocal stack) (CmmLoad (cmmOffset dflags (CmmReg
> (CmmLocal tso)) (tso_stackobj dflags)) (bWord dflags)),
> (...)
> 
> So I believe the instruction are mapped like this:
> 
> ldr	r1, [r0, #140]  <-> tso = CurrentTSO
> ldr	r12, [r1, #12]  <-> stack = tso->stackobj
> 
> If that is true, the loaded tso pointer ([r0, #140]) must be wrong.
> 
> When I look at the backtrace at the moment of crash:
> 
> #0  0x003f0588 in stg_returnToStackTop ()
> #1  0x003c2e74 in schedule (initialCapability=0x3f057c, task=0x52f350)
>     at rts/Schedule.c:463
> #2  0x003c2e74 in schedule (initialCapability=0x52f340, task=0x400a42f0)
>     at rts/Schedule.c:463
> #3  0x003c4cb0 in scheduleWaitThread (tso=0x401033c0, ret=0x0,
> pcap=0xbe843b6c)
>     at rts/Schedule.c:2351
> 
> There is a "tso" value passed to scheduleWaitThread (tso=0x401033c0).
> Should be this is the same address, form where the tso is loaded in the
> instruction:
> 
> ldr	r1, [r0, #140]  <-> tso = CurrentTSO
> 
> ? If so, the value in r0 is way of.
> 
> info register
> r0             0x3f057c	4130172
> r1             0xe24dd010	-498216944
> 
> 
> Are my conclusions so far correct, and I have to find out why r0 is
> having the wrong value?
> 
> Thanks!
> Nathan
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>