[Webkit-unassigned] [Bug 211592] New: CLoop JSC broken on 32-bit big endian

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=211592

            Bug ID: 211592
           Summary: CLoop JSC broken on 32-bit big endian
           Product: WebKit
           Version: Other
          Hardware: Other
                OS: Linux
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: JavaScriptCore
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: daniel at octaforge.org

Created attachment 398788

  --> https://bugs.webkit.org/attachment.cgi?id=398788&action=review

proposed patch

For quite a few versions, CLoop JSC has been broken on 32-bit BE (e.g. 32-bit PowerPC). I tried debugging around it some time ago and found that specifically on 32-bit BE platforms, some things need offsetting by PayloadOffset (4 on BE, 0 on LE, regardless of 32-bit or 64-bit), just like is done in various other places already, presumably because on 32-bit BE you might have 32-bit values in 64-bit storage at an offset.

I attached the proposed patch. With this, all versions of WebKit I've had access to (including latest master) work on 32-bit BE (tested on a PowerBook G4; we've shipped a variant of this in my distribution at least since WebKit Gtk 2.24). I'm not sure if the JSVALUE64 ifs are needed in these specific paths, that would need figuring out if those paths ever get called on 64-bit, since on 64-bit BE WebKit works perfectly fine even now. That said, I tried the patch without the conditional JSVALUE64 checking and it also seems to have worked on both 32 and 64-bit BE - I put them there to be on the safe side (in order to possibly not regress some edge cases for 64-bit BE).

Could someone with knowledge of these code paths pitch in and say if JSVALUE64 needs to be checked or not, or possibly where?

For now this is here for review. Once it gets some feedback, I can make it into a proper patch with a ChangeLog entry and so on.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20200507/d30cae7d/attachment-0001.htm>