fourthTier: CallFrame::trueCallFrame() should populate the bytecodeOffset field
when reifying inlined frames..
https://bugs.webkit.org/show_bug.cgi?id=117209.
Reviewed by Geoffrey Garen.
When reifying an inlined frame, we fill in its CodeBlock, and
bytecodeOffset. We also set the InlinedFrame bit in the location field.
This is needed in order to iterate the stack correctly. Here's why:
Let's say we have the following stack trace:
X calls A inlines B inlines C calls D
Based on the above scenario,
- D's callerFrame points to A (not C).
- A has a codeOriginIndex that points to C.
When iterating the stack (from D back towards X), we will encounter A
twice:
t1. when trying to find C as D's caller.
This is the time when we reify B and C using the
codeOriginIndex in A, and return C as the caller frame of D.
t2. when getting's the reified B's caller.
This time, we don't run the reification process, and
just take A as the caller frame of B.
To discern which treatment of the DFG frame (i.e. A) we need to apply,
we check if the callee is an inlined frame:
If callee is NOT an inlined frame (e.g. frame D), apply treatment t1.
If callee is an inlined frame (e.g. frame B), apply treatment t2.
Why not just reify A by replacing its codeOriginIndex with A's
bytecodeOffset?
We can't do this because D's callerFrame pointer still points to A, and
needs to remain that way because we did not deopt A. It remains a DFG
frame which inlined B and C.
If we replace the codeOriginIndex in A with A's bytecodeOffset, we will
only get to iterate the stack correctly once. If we try to iterate the
stack a second time, we will not have the information from the
codeOriginIndex to tell us that D's caller is actually the inlined C,
and not A.
To recap, when reifying frames for stack iteration purposes, the DFG
frame needs to hold on to its codeOriginIndex. This in turn means the
DFG frame will need to be treated in 2 possible ways, and we need to
know if a callee frame is an inlined frame in order to choose the
correct treatment for the DFG frame.
Other changes:
- Simplified Interpreter::getCallerInfo().
- Removed CodeBlock::codeOriginForReturn() and supporting code
which is now unneeded.
- Moved CallFrame location bit encoding from the CodeOrigin to the
new CallFrame::Location class.
- Explicitly tagged inlined frames. This is necessary in order to
iterate the stack correctly as explained above.
- bytecode/CodeBlock.cpp:
- bytecode/CodeBlock.h:
(JSC::CodeBlock::codeOrigins):
(CodeBlock):
(JSC::CodeBlock::codeOrigin):
(RareData):
(CodeOrigin):
(JSC::DFG::JITCompiler::link):
(JSC::DFG::JITCompiler::beginCall):
- interpreter/CallFrame.cpp:
(JSC::CallFrame::trueCallFrame):
(JSC::CallFrame::trueCallerFrame):
(JSC::CallFrame::bytecodeOffsetFromCodeOriginIndex):
(Location):
(ExecState):
(JSC::ExecState::trueCallerFrame):
(JSC::ExecState::callerFrameNoFlags):
- interpreter/CallFrameInlines.h:
(JSC::CallFrame::Location::encode):
(JSC::CallFrame::Location::decode):
(JSC::CallFrame::Location::isBytecodeOffset):
(JSC::CallFrame::Location::isCodeOriginIndex):
(JSC::CallFrame::Location::isInlinedFrame):
(JSC::CallFrame::isInlinedFrame):
(JSC::CallFrame::setIsInlinedFrame):
(JSC::CallFrame::hasLocationAsBytecodeOffset):
(JSC::CallFrame::hasLocationAsCodeOriginIndex):
(JSC::CallFrame::locationAsBytecodeOffset):
(JSC::CallFrame::setLocationAsBytecodeOffset):
(JSC::CallFrame::locationAsCodeOriginIndex):
- interpreter/Interpreter.cpp:
(JSC::getCallerInfo):
(JSC::Interpreter::getStackTrace):
(JSC::Interpreter::findFunctionCallFrameFromVMCode):
(JSC::Arguments::tearOff):
