ASSERT(hasLocationAsBytecodeOffset()) is called in CallFrame::locationAsBytecodeOffset() and CallFrame::setLocationAsBytecodeOffset() for JSVALUE32_64 builds. The 32 bit value stored in ArgumentCount tag for the JSVALUE32_64 builds is a pointer which may have the high bit set. This high bit is used to determine whether hasLocationAsBytecodeOffset() or hasLocationAsCodeOriginIndex() is true. Therefore these checks are meaningless to 32 bit builds. I believe that some of the work in https://bugs.webkit.org/show_bug.cgi?id=117262 needs to be changed for 32 bit builds.
(In reply to comment #0) > ASSERT(hasLocationAsBytecodeOffset()) is called in CallFrame::locationAsBytecodeOffset() and CallFrame::setLocationAsBytecodeOffset() for JSVALUE32_64 builds. The 32 bit value stored in ArgumentCount tag for the JSVALUE32_64 builds is a pointer which may have the high bit set. This high bit is used to determine whether hasLocationAsBytecodeOffset() or hasLocationAsCodeOriginIndex() is true. Therefore these checks are meaningless to 32 bit builds. > > I believe that some of the work in https://bugs.webkit.org/show_bug.cgi?id=117262 needs to be changed for 32 bit builds. Yes, ideally, we should fix the 64 bit port so that its offset is in units of bytes instead of int64_t's. That will allow us to use the low 2 bits for flags.
Actually, I can implement a quick fix for this using the patch I'll land for https://bugs.webkit.org/show_bug.cgi?id=117209.
Created attachment 203966 [details] the patch.
Comment on attachment 203966 [details] the patch. View in context: https://bugs.webkit.org/attachment.cgi?id=203966&action=review r=me > Source/JavaScriptCore/ChangeLog:7 > + Add some text saying that we are using the low 2 bits and the reason is that the upper bits are needed for addresses.
Thanks for the review. Landed in r151291: <http://trac.webkit.org/changeset/151291>.