Title: [212877] trunk/Source/_javascript_Core
- Revision
- 212877
- Author
- [email protected]
- Date
- 2017-02-22 22:35:50 -0800 (Wed, 22 Feb 2017)
Log Message
WebAssembly: clear out insignificant i32 bits when calling _javascript_
https://bugs.webkit.org/show_bug.cgi?id=166677
Reviewed by Keith Miller.
When WebAssembly calls _javascript_ it needs to clear out the
insignificant bits of int32 values:
+------------------- tag
| +---------------- insignificant
| | +------------ 32-bit integer value
| | |
|--|---|-------|
0xffff0000ffffffff
At least some _javascript_ code assumes that these bits are all
zero. In the wasm-to-wasm.js example we store a 64-bit value in an
object with lo / hi fields, each containing 32-bit integers. We
then load these back, and the baseline compiler fails its
comparison because it first checks the value are the same type
(yes, because the int32 tag is set in both), and then whether they
have the same value (no, because comparing the two registers
fails). We could argue that the baseline compiler is wrong for
performing a 64-bit comparison, but it doesn't really matter
because there's not much of a point in breaking that invariant for
WebAssembly's sake.
* wasm/WasmBinding.cpp:
(JSC::Wasm::wasmToJs):
Modified Paths
Diff
Modified: trunk/Source/_javascript_Core/ChangeLog (212876 => 212877)
--- trunk/Source/_javascript_Core/ChangeLog 2017-02-23 06:11:02 UTC (rev 212876)
+++ trunk/Source/_javascript_Core/ChangeLog 2017-02-23 06:35:50 UTC (rev 212877)
@@ -1,3 +1,35 @@
+2017-02-22 JF Bastien <[email protected]>
+
+ WebAssembly: clear out insignificant i32 bits when calling _javascript_
+ https://bugs.webkit.org/show_bug.cgi?id=166677
+
+ Reviewed by Keith Miller.
+
+ When WebAssembly calls _javascript_ it needs to clear out the
+ insignificant bits of int32 values:
+
+ +------------------- tag
+ | +---------------- insignificant
+ | | +------------ 32-bit integer value
+ | | |
+ |--|---|-------|
+ 0xffff0000ffffffff
+
+ At least some _javascript_ code assumes that these bits are all
+ zero. In the wasm-to-wasm.js example we store a 64-bit value in an
+ object with lo / hi fields, each containing 32-bit integers. We
+ then load these back, and the baseline compiler fails its
+ comparison because it first checks the value are the same type
+ (yes, because the int32 tag is set in both), and then whether they
+ have the same value (no, because comparing the two registers
+ fails). We could argue that the baseline compiler is wrong for
+ performing a 64-bit comparison, but it doesn't really matter
+ because there's not much of a point in breaking that invariant for
+ WebAssembly's sake.
+
+ * wasm/WasmBinding.cpp:
+ (JSC::Wasm::wasmToJs):
+
2017-02-22 Keith Miller <[email protected]>
Remove the demand executable allocator
Modified: trunk/Source/_javascript_Core/wasm/WasmBinding.cpp (212876 => 212877)
--- trunk/Source/_javascript_Core/wasm/WasmBinding.cpp 2017-02-23 06:11:02 UTC (rev 212876)
+++ trunk/Source/_javascript_Core/wasm/WasmBinding.cpp 2017-02-23 06:35:50 UTC (rev 212877)
@@ -155,6 +155,7 @@
frOffset += sizeof(Register);
}
++marshalledGPRs;
+ jit.zeroExtend32ToPtr(gprReg, gprReg); // Clear non-int32 and non-tag bits.
jit.boxInt32(gprReg, JSValueRegs(gprReg), DoNotHaveTagRegisters);
jit.store64(gprReg, calleeFrame.withOffset(calleeFrameOffset));
calleeFrameOffset += sizeof(Register);
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
