[webkit-dev] (Legacy 2.1.1) LLINT: _llint_program_prologue CodeBlock::m_instructions[0] is NULL

[Geoffrey Garen]

The CodeBlock constructor is responsible for filling m_instructions. I’d start there.

Geoff

> On Aug 26, 2015, at 9:46 AM, Bryan Woodruff <bryan.woodruff at boxspy.com> wrote:
> 
> Apologies in advance for cross-posting – not seeing any activity on webkit-help.
>  
> Caveat: Due to divergence in the code base and the target platform, I’m working with an older port based on v2.1.1.  But, I believe my question is broad enough that someone may be able to help point me in the right area.
>  
> I’m enabling LLINT which was not enabled for the port we’re working with in this version.   In the dispatch to llint_program_prologue, the CodeBlock.m_instructions[0] points to the value 0 which results into a jmp to 0 and a subsequent access violation.
>  
> I’m looking to understand what conditions cause CodeBlock.m_instructions[0] to not point to code.   Both JIT and LLINT are enabled.
>  
> JSC::prepareForExecution builds a CTI stub with programEntryThunkGenerator, the prologue thunk executes and lands in the prologue code.  I verified that the CodeBlock processed in prologue is the CodeBlock set up by this stack:
>  
> x!JSC::prepareForExecution<JSC::ProgramCodeBlock>(JSC::ExecState *, WTF::OwnPtr<JSC::ProgramCodeBlock> & {...}, JSC::JITCode & {...}, JSC::JITCode::JITType BaselineJIT, unsigned int) executionharness.h line 42
> x!JSC::ProgramExecutable::compileInternal(JSC::ExecState *, JSC::JSScope *, JSC::JITCode::JITType BaselineJIT, unsigned int) executable.cpp line 328 + 19 bytes
> x!JSC::ProgramExecutable::compile(JSC::ExecState *, JSC::JSScope *) executable.h line 514 + 19 bytes
>  
> Note that this code path is not taken as the profiler is not enabled, I’m not clear as to the design if this would impact this 0 index of m_instructions or not.
>  
>         if (exec->vm().m_perBytecodeProfiler)
>             exec->vm().m_perBytecodeProfiler->ensureBytecodesFor(codeBlock.get());
>  
> After the prepareForExecution and going through the thunk, it’s the processing of the CodeBlock that lands the instruction pointer at 0.  The offset of m_instructions looks correct comparing the offset with other assembly generated for other modules (including CodeBlock.cpp itself).   Inspecting the CodeBlock object and m_instructions[0] verifies it has a 0 in this entry.   I am assuming this is unexpected – but I don’t understand where this is supposed to be set up when tracing step-by-step through this code path.
>  
> Any suggestions/pointers appreciated.
>  
> Thanks!
>  
>  
> _llint_program_prologue:
>     prologue(notFunctionCodeBlockGetter, notFunctionCodeBlockSetter, _llint_entry_osr, _llint_trace_prologue)
>     dispatch(0)
>  
>  
>     # Set up the PC.
>    if JSVALUE64
>         loadp CodeBlock::m_instructions[t1], PB
>         move 0, PC
>     else
>         loadp CodeBlock::m_instructions[t1], PC
>     end
>  
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org <mailto:webkit-dev at lists.webkit.org>
> https://lists.webkit.org/mailman/listinfo/webkit-dev <https://lists.webkit.org/mailman/listinfo/webkit-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-dev/attachments/20150826/a3eee898/attachment.html>