[Webkit-unassigned] [Bug 123848] New: crash when executing Thunk checks on ARM

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Nov 5 19:07:13 PST 2013


https://bugs.webkit.org/show_bug.cgi?id=123848

           Summary: crash when executing Thunk checks on ARM
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: Unspecified
        OS/Version: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: JavaScriptCore
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: mandeep.baines at gmail.com


I'm getting a crash when executing the thunk checks from code generated by virtualForThunkGenerator.

I think this is a regression introduced when JIT was migrated to use the same thunks as DFG:

Author: msaboff at apple.com <msaboff at apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc
>
Date:   Wed Oct 9 13:29:00 2013 +0000

    Transition call and construct JITStubs to CCallHelper functions
    https://bugs.webkit.org/show_bug.cgi?id=122453

    Reviewed by Geoffrey Garen.

    Transitioned cti_op_call_eval to operationCallEval.  Migrated baseline JIT to
 use the same
    call thunks as the DFG.  Eliminated all of the "oldStyle" thunks and related 
functions.

...    

    git-svn-id: http://svn.webkit.org/repository/webkit/trunk@157164 268f45cc-cd0
9-0410-ab3c-d52691b4dbfc

The check is generated here:

<snip>
static MacroAssemblerCodeRef virtualForThunkGenerator(
    VM* vm, CodeSpecializationKind kind)
{
    // The return address is on the stack, or in the link register. We will henc\
e                                                                                
    // jump to the callee, or save the return address to the call frame while we
    // make a C++ function call to the appropriate JIT operation.                

    CCallHelpers jit(vm);

    CCallHelpers::JumpList slowCase;

    // FIXME: we should have a story for eliminating these checks. In many cases\
,                                                                                
    // the DFG knows that the value is definitely a cell, or definitely a functi\
on.                                                                              

#if USE(JSVALUE64)
    slowCase.append(
        jit.branchTest64(
            CCallHelpers::NonZero, GPRInfo::nonArgGPR0, GPRInfo::tagMaskRegister\
));
#else
    slowCase.append(
        jit.branch32(
            CCallHelpers::NotEqual, GPRInfo::nonArgGPR1,
            CCallHelpers::TrustedImm32(JSValue::CellTag)));
#endif
    jit.loadPtr(CCallHelpers::Address(GPRInfo::nonArgGPR0, JSCell::structureOffs\
et()), GPRInfo::nonArgGPR2);
    slowCase.append(
        jit.branchPtr(
            CCallHelpers::NotEqual,
            CCallHelpers::Address(GPRInfo::nonArgGPR2, Structure::classInfoOffse\
t()),
            CCallHelpers::TrustedImmPtr(JSFunction::info())));
</snip>

It is expecting the callee to be stored in nonArgGPR1 and nonArgGPR0.

However, the JIT path is storing the callee is in regT1 and regT0 if you look at JIT::compileOpCall.

This used to work because the check used to be generated by oldStyleLinkForGenerator which checked regT0 and regT1.

-static MacroAssemblerCodeRef oldStyleVirtualForGenerator(VM* vm, FunctionPtr compile, FunctionPtr notJSFunction, const char* name, CodeSpecializationKind kind)
-{
-    JSInterfaceJIT jit(vm);
-    
-    JSInterfaceJIT::JumpList slowCase;
-
-#if USE(JSVALUE64)    
-    slowCase.append(jit.emitJumpIfNotJSCell(JSInterfaceJIT::regT0));
-#else // USE(JSVALUE64)
-    slowCase.append(jit.branch32(JSInterfaceJIT::NotEqual, JSInterfaceJIT::regT1, JSInterfaceJIT::TrustedImm32(JSValue::CellTag)));
-#endif // USE(JSVALUE64)
-    slowCase.append(jit.emitJumpIfNotType(JSInterfaceJIT::regT0, JSInterfaceJIT::regT1, JSFunctionType));
-

I think the correct fix is to modify virtualForThunkGenerator to use regT0 and regT1.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list