[Webkit-unassigned] [Bug 97569] Assertion failure in non-JIT'ed LLInt on ARM Thumb

[bugzilla-daemon at webkit.org]

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





--- Comment #8 from Cosmin Truta <ctruta at gmail.com>  2013-11-01 22:50:36 PST ---
Thank you, Mark. Essentially, ASSERT_VALID_CODE_POINTER becomes a mere ASSERT.

But since I filed this patch, many moons ago, I discovered other failures, similar in nature, but due to a different cause: thumb-interwork thunks. See the following backtrace snippet (collected a while ago on ARM Linux):

#1  0x76adda10 in JSC::FunctionPtr::FunctionPtr<int, double> (this=0x7effadb4, value=0xc6c0 <JSC::toInt32(double)>)
    at ~/WebKit/Source/JavaScriptCore/assembler/MacroAssemblerCodeRef.h:105
#2  0x76ad9bec in JSC::DFG::SpeculativeJIT::callOperation (this=0x7effd798, operation=0xc6c0 <JSC::toInt32(double)>, 
    result=JSC::ARMRegisters::r0, arg1=JSC::ARMRegisters::d0)
    at ~/WebKit/Source/JavaScriptCore/dfg/DFGSpeculativeJIT.h:1314
#3  0x76aca8b8 in JSC::DFG::SpeculativeJIT::compileValueToInt32 (this=0x7effd798, node=0x738e14f8)
    at ~/WebKit/Source/JavaScriptCore/dfg/DFGSpeculativeJIT.cpp:2311

This is happening because JSC::toInt32 is exported from libJavaScriptCore.so, and the exports are done via thunks.

So removing the check for decorated code pointers inside createFromExecutableAddress() isn't sufficient. It also needs to be removed from the FunctionPtr constructor. What do you think about that?

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