openwrt/video
1
0
Fork 0
mirror of https://github.com/openwrt/video.git synced 2026-05-31 23:12:10 +08:00
Code Issues Packages Projects Releases Wiki Activity

wpewebkit: update to version 2.52.3

Browse Source 
Update WPEWebKit to the 2.52 stable major release branch.

Includes a pending patchset to get WASM BBQJIT working on RISCV64,
upstream PR https://github.com/WebKit/WebKit/pull/65621

Alltogether this brings acceptable performance (even with LLVMPipe
Mesa software renderer) on RISCV64.

Link: https://wpewebkit.org/release/wpewebkit-2.52.0.html
Link: https://wpewebkit.org/release/wpewebkit-2.52.1.html
Link: https://wpewebkit.org/release/wpewebkit-2.52.2.html
Link: https://wpewebkit.org/release/wpewebkit-2.52.3.html
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
This commit is contained in:
Daniel Golle
2026-05-09 01:37:44 +01:00
parent be41d2f4dc
commit df0b899123
38 changed files with 4904 additions and 25 deletions
Download Patch File Download Diff File Expand all files Collapse all files
libs/wpewebkit/patches/151-JavaScriptCore-RISCV64-disable-useWasmFastMemory.patch
+54
View File
@@ -0,0 +1,54 @@
From: Daniel Golle <daniel@makrotopia.org>
Subject: [PATCH] JavaScriptCore: disable useWasmFastMemory on RISCV64
Base RISC-V doesn't require stores that fault to be atomic w.r.t. the
fault: hardware may commit some in-bound bytes of a 2/4/8-byte store
before raising the page-fault exception when the access straddles a
page boundary into PROT_NONE memory. SiFive U74 (StarFive JH7110)
does this.
JSC's "fast memory" mode (useWasmFastMemory=true) relies on the
SIGBUS/SIGSEGV handler to convert OOB accesses into wasm traps without
an explicit bounds check. The handler observes the fault and traps the
wasm correctly, but the in-bounds bytes already corrupted by the partial
commit remain in memory. Subsequent reads see wrong data.
Reproducer: spec-tests/memory_trap.wast.js #295. Test 51 of the same
file does i32.store at offset 65535 (1 in-bound byte, 3 OOB bytes);
expected to trap. The trap fires but byte 65535 gets clobbered to 0
before the fault. Later test #295 reads i64 at offset 65528 (covering
bytes 65528..65535) and finds 0x0067666564636261 instead of
0x6867666564636261 -- the assertion against the i64 const trips the
wasm "unreachable" guard.
Force-disable useWasmFastMemory on RISCV64; bounds checking falls back
to the explicit BoundsChecking mode in emitCheckAndPreparePointer,
which checks the access upper bound against the memory size before
issuing any load/store.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
---
--- a/Source/JavaScriptCore/runtime/Options.cpp
+++ b/Source/JavaScriptCore/runtime/Options.cpp
@@ -804,6 +804,21 @@ void Options::notifyOptionsChanged()
#endif
#endif
+#if CPU(RISCV64)
+ // The base RISC-V ISA permits a faulting store to commit some of its
+ // bytes before raising the exception (single-copy atomicity is only
+ // guaranteed for naturally-aligned accesses up to XLEN, not for a
+ // store that straddles a page boundary into PROT_NONE). On hardware
+ // that does this (e.g. SiFive U74 in JH7110), JSC's signal-based
+ // bounds check sees the page fault but the in-bounds bytes have
+ // already been corrupted -- subsequent reads return wrong values.
+ // Force explicit bounds checking instead. Reproducer:
+ // spec-tests/memory_trap.wast.js #295 (i32.store at 65535 partially
+ // overwrites byte 65535 before trapping, then i64.load at 65528
+ // sees the corrupted high byte).
+ Options::useWasmFastMemory() = false;
+#endif
+
#if !CPU(ARM64)
Options::useRandomizingExecutableIslandAllocation() = false;
#endif