[webkit-dev] does jit uses self-modifying code?
x yz
lastguy at yahoo.com
Fri May 29 18:28:46 PDT 2009
Hi,
Appreciate for help. If the answer is yes may I know here are they.
MIPS webkit-1.1.1, cmd using: jsc shell.js
In JavaScriptCore/runtime/JSObject.h:527
asCell()->put(exec, propertyName, value, slot);
this one will call a function, yet the function entry address got is invalid.
0x006b17ec 527 asCell()->put(exec, propertyName, value, slot);
(gdb) x/10i $pc
0x6b17ec <_ZN3JSC10JSValuePtr3putEPNS_9ExecStateERKNS_10IdentifierES0_RNS_15PutPropertySlotE+196>: lw gp,24(s8)
0x6b17f0 <_ZN3JSC10JSValuePtr3putEPNS_9ExecStateERKNS_10IdentifierES0_RNS_15PutPropertySlotE+200>: move v1,v0
0x6b17f4 <_ZN3JSC10JSValuePtr3putEPNS_9ExecStateERKNS_10IdentifierES0_RNS_15PutPropertySlotE+204>: lw a0,0(v1)
0x6b17f8 <_ZN3JSC10JSValuePtr3putEPNS_9ExecStateERKNS_10IdentifierES0_RNS_15PutPropertySlotE+208>: lw a3,60(s8)
0x6b17fc <_ZN3JSC10JSValuePtr3putEPNS_9ExecStateERKNS_10IdentifierES0_RNS_15PutPropertySlotE+212>: lw v0,64(s8)
0x6b1800 <_ZN3JSC10JSValuePtr3putEPNS_9ExecStateERKNS_10IdentifierES0_RNS_15PutPropertySlotE+216>: sw v0,16(sp)
0x6b1804 <_ZN3JSC10JSValuePtr3putEPNS_9ExecStateERKNS_10IdentifierES0_RNS_15PutPropertySlotE+220>: lw t9,68(a0)
0x6b1808 <_ZN3JSC10JSValuePtr3putEPNS_9ExecStateERKNS_10IdentifierES0_RNS_15PutPropertySlotE+224>: move a0,v1
0x6b180c <_ZN3JSC10JSValuePtr3putEPNS_9ExecStateERKNS_10IdentifierES0_RNS_15PutPropertySlotE+228>: lw a1,52(s8)
0x6b1810 <_ZN3JSC10JSValuePtr3putEPNS_9ExecStateERKNS_10IdentifierES0_RNS_15PutPropertySlotE+232>: lw a2,56(s8)
the entry got is $t9=0x2bc that is wrong.
rgds
joe
--- On Sat, 5/9/09, x yz <lastguy at yahoo.com> wrote:
> From: x yz <lastguy at yahoo.com>
> Subject: Re: [webkit-dev] random seg fault on MIPS platform
> To: webkit-dev at lists.webkit.org
> Date: Saturday, May 9, 2009, 1:24 AM
>
> Hi,
> >50% of time when I use gdb then arith functions works.
> it may fail at 1st, or 3rd try, and 100% fail w/o gdb. I
> just use jsc to do sth like 5%2, 5*3, etc.
>
> It is with in call of ctiTrampoline(code, registerFile,
> callFrame, jexception, pptr, globalData), jit code executed
> and may be in last line of op_mod() when it tried to convert
> result, gdb simply shows segment fault, or PC stops at an
> non-coded area, w/o gdb it says invalid instruction. It may
> be in JITcell,h in
> ALWAYS_INLINE double JSValuePtr::toNumber(ExecState* exec)
> const
> {
> return
> JSImmediate::isImmediate(asValue()) ?
> JSImmediate::toDouble(asValue()) :
> asCell()->toNumber(exec);
> }
> due to exec pointer wrong.
>
> if I continue to use same arithmatic function the generated
> jit code won't call op_mod() unless it is the 1st time, I
> think it is because jit code is already there. If another
> thread handles the real operation and not sync'd then it may
> be the case. Note I use BCM chip with two CPUs - BCM
> customized SMP and BCM Linux.
>
> when it works, before and after ctiTrampoline() the stack
> is balanced and registers are ok. where is the jit stack and
> how to check its balance?
>
> when it fails, stacks shows we are nearby jit code - the
> code w/o calling OP_mod() CPP function as it fails at 3rd
> try. But PC points to a data structure:
> any comments? thanks a lot!!
> rgds
> joe
>
> //////////////
> (gdb) c
> Continuing.
>
> Program received signal SIGILL, Illegal instruction.
> 0x2aacd000 in ?? ()
> (gdb) where
> #0 0x2aacd000 in ?? ()
> warning: GDB can't find the start of the function at
> 0x2aacd000.
> ...
> #1 0x2aacd000 in ?? ()
> warning: GDB can't find the start of the function at
> 0x2aaccfff.
> Backtrace stopped: previous frame identical to this frame
> (corrupt stack?)
> (gdb) backtrace
> #0 0x2aacd000 in ?? ()
> #1 0x2aacd000 in ?? ()
> Backtrace stopped: previous frame identical to this frame
> (corrupt stack?)
> (gdb) p/x $sp
> $1 = 0x7fa439d8
> (gdb) p/x $pc
> $2 = 0x2aacd000
> (gdb) p/x $t9
> $3 = 0x2aac9588
> (gdb) x/10i $t9 = jit code, no actual call to op_mod() cpp
> function
> 0x2aac9588: sw
> ra,-40(s5)
> 0x2aac958c: lui s7,0x0
> 0x2aac9590: ori
> s7,s7,0xa
> 0x2aac9594: sw
> s7,0(s5)
> 0x2aac9598: lui s7,0x0
> 0x2aac959c: ori
> s7,s7,0xa
> 0x2aac95a0: sw
> s7,8(s5)
> 0x2aac95a4: lui v0,0x0
> 0x2aac95a8: ori
> v0,v0,0xa
> 0x2aac95ac: sw
> v0,32(s5)
> (gdb)
> 0x2aac95b0: lui
> v0,0xffff
> 0x2aac95b4: ori
> v0,v0,0xffff
> 0x2aac95b8: sw
> v0,32(s5)
> 0x2aac95bc: lw
> at,-40(s5)
> 0x2aac95c0: nop
> 0x2aac95c4: addiu
> sp,sp,-4
> 0x2aac95c8: sw
> at,0(sp)
> 0x2aac95cc: lw
> ra,0(sp)
> 0x2aac95d0: addiu
> sp,sp,4
> 0x2aac95d4: jr ra
> 0x2aac95d8: nop
> (gdb) p/x $ra //$ra = tobe returned addr after
> ctiTrampoline(), correct
> $4 = 0x676d64
> (gdb) x/10i $pc //sth not patched well??
> 0x2aacd000: 0x4941444a
> 0x2aacd004: jalx
> 0x21a5a881
> 0x2aacd008: j
> 0x2984c8b4
> 0x2aacd00c: andi
> at,s3,0x3134
> 0x2aacd010: 0x6d202c30
> 0x2aacd014: 0x7a69735f
> 0x2aacd018: 0x66373d65
> 0x2aacd01c: xori
> s3,t1,0x3461
> 0x2aacd020: ori
> t0,t1,0x3864
> 0x2aacd024: addi
> t4,at,10544
> (gdb)
> 0x2aacd028: jalx
> 0x25b185d9
> 0x2aacd02c: j
> 0x28c0f594
> 0x2aacd030: andi
> s0,at,0x3030
> 0x2aacd034: 0x720a0a38
> 0x2aacd038: 0x64496765
> 0x2aacd03c: j
> 0x28e0c4f4
> 0x2aacd040: nop
> 0x2aacd044: nop
> 0x2aacd048: nop
> 0x2aacd04c: nop
>
> 0x2aacd028: jalx
> 0x25b185d9
> 0x2aacd02c: j
> 0x28c0f594
> 0x2aacd030: andi
> s0,at,0x3030
> 0x2aacd034: 0x720a0a38
> 0x2aacd038: 0x64496765
> 0x2aacd03c: j
> 0x28e0c4f4
> 0x2aacd040: nop
>
>
>
>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
More information about the webkit-dev
mailing list