Re: Understand disassemble for segfault on android

2013-01-13 Thread 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-d...@haskell.org
 http://www.haskell.org/mailman/listinfo/ghc-devs
 


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


Understand disassemble for segfault on android

2013-01-12 Thread Nathan Hüsken
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

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users