mirror of
https://github.com/openwrt/video.git
synced 2026-05-31 06:51:54 +08:00
Daniel Golle
df0b899123
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>
55 lines
2.5 KiB
Diff
55 lines
2.5 KiB
Diff
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
|