| Summary: | Encode CallFrame::Location flags in the low bits when USE(JSVALUE32_64). | ||||||
|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Michael Saboff <msaboff> | ||||
| Component: | JavaScriptCore | Assignee: | Mark Lam <mark.lam> | ||||
| Status: | RESOLVED FIXED | ||||||
| Severity: | Normal | CC: | mark.lam | ||||
| Priority: | P2 | ||||||
| Version: | 528+ (Nightly build) | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| Bug Depends on: | |||||||
| Bug Blocks: | 117262 | ||||||
| Attachments: |
|
||||||
|
Description
Michael Saboff
2013-06-06 11:17:51 PDT
(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>. |