[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


Mark Lam <mark.lam at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #167385|review?                     |review-
               Flag|                            |




--- Comment #7 from Mark Lam <mark.lam at apple.com>  2013-10-31 12:28:04 PST ---
(From update of attachment 167385)
View in context: https://bugs.webkit.org/attachment.cgi?id=167385&action=review

> Source/JavaScriptCore/assembler/MacroAssemblerCodeRef.h:291
> +#if CPU(ARM_THUMB2) && ENABLE(COMPUTED_GOTO_OPCODES)
> +        // ASSERT_VALID_CODE_POINTER is not applicable to opcodes coming from
> +        // addresses of labels, because they are not decorated on ARM Thumb.
> +        ASSERT(value);
> +#else

createFromExecutableAddress() is called from createLLIntCodePtr() amongst other places.  createLLIntCodePtr() takes a LLIntCode which gets casted to the void* arg passed to createFromExecutableAddress().  And LLintCode is always an OpcodeId when ENABLE(LLINT_C_LOOP).  Hence, LLIntCode can be an OpcodeId regardless of whether ENABLE(COMPUTED_GOTO_OPCODES) or not.  Since, OpcodeIds are not guaranteed to have the low bit set, you'll never want to use ASSERT_VALID_CODE_POINTER() when building for CPU(ARM_THUMB2).

Hence, you should omit the ENABLE(COMPUTED_GOTO_OPCODES) condition altogether.  Please fix and upload another patch.

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