[webkit-changes] [WebKit/WebKit] bc5e8d: Cherry-pick 283286.567 at safari-7620-branch (8964a07...
Yusuke Suzuki
noreply at github.com
Thu Jan 30 11:10:30 PST 2025
Branch: refs/heads/webkitglib/2.46
Home: https://github.com/WebKit/WebKit
Commit: bc5e8dbe418afbd1d39c79cd9550bc181d19e557
https://github.com/WebKit/WebKit/commit/bc5e8dbe418afbd1d39c79cd9550bc181d19e557
Author: David Degazio <d_degazio at apple.com>
Date: 2025-01-30 (Thu, 30 Jan 2025)
Changed paths:
A JSTests/wasm/stress/array-copy-with-constant-null.js
M Source/JavaScriptCore/wasm/WasmBBQJIT.cpp
M Source/JavaScriptCore/wasm/WasmBBQJIT.h
M Source/JavaScriptCore/wasm/WasmBBQJIT32_64.cpp
M Source/JavaScriptCore/wasm/WasmBBQJIT64.cpp
M Source/JavaScriptCore/wasm/WasmFunctionParser.h
M Source/JavaScriptCore/wasm/WasmTypeDefinition.h
M Source/JavaScriptCore/wasm/generateWasm.py
M Source/JavaScriptCore/wasm/generateWasmOpsHeader.py
Log Message:
-----------
Cherry-pick 283286.567 at safari-7620-branch (8964a07ea3fb). https://bugs.webkit.org/show_bug.cgi?id=283889
[WASM GC] Reference instructions should consume arguments even when operand is constant null
https://bugs.webkit.org/show_bug.cgi?id=283889
rdar://140774231
Reviewed by Yusuke Suzuki.
Fixes all instances where we have a WASM GC opcode that fails to call
consume() on its arguments. Generally this previously happened in the
case we detected one of the arguments was a JSNull constant.
In order to limit the impact of failing to consume(), this patch also
removes a case in BBQJIT::allocateWithHint that would blindly reuse
the existing register binding for a value. This case seems to only have
been reachable when calling allocate() on the result of a C call - a
procedure that allocates a location for its result internally. I've
replaced these redundant allocate() calls with loadIfNecessary() calls,
although we pretty much always expect the value to already be in a
register.
Finally, this patch adds debug-only verification that every value we
pop from the expression stack is consumed in BBQ. This required some
minor changes to the implementations of some instructions to ensure
we don't detect spurious errors. It was a big help in finding buggy
cases when making this patch and should help defend against such bugs
in the future.
Modified by Michael Catanzaro to add python script changes from
282799 at main.
* JSTests/wasm/stress/array-copy-with-constant-null.js: Added.
* Source/JavaScriptCore/wasm/WasmBBQJIT.cpp:
(JSC::Wasm::BBQJITImpl::BBQJIT::addTableSet):
(JSC::Wasm::BBQJITImpl::BBQJIT::addTableInit):
(JSC::Wasm::BBQJITImpl::BBQJIT::addTableFill):
(JSC::Wasm::BBQJITImpl::BBQJIT::addTableCopy):
(JSC::Wasm::BBQJITImpl::BBQJIT::addMemoryFill):
(JSC::Wasm::BBQJITImpl::BBQJIT::addMemoryCopy):
(JSC::Wasm::BBQJITImpl::BBQJIT::addMemoryInit):
(JSC::Wasm::BBQJITImpl::BBQJIT::atomicWait):
(JSC::Wasm::BBQJITImpl::BBQJIT::atomicNotify):
(JSC::Wasm::BBQJITImpl::BBQJIT::pushArrayNewFromSegment):
(JSC::Wasm::BBQJITImpl::BBQJIT::addArrayCopy):
(JSC::Wasm::BBQJITImpl::BBQJIT::addArrayInitElem):
(JSC::Wasm::BBQJITImpl::BBQJIT::addArrayInitData):
(JSC::Wasm::BBQJITImpl::BBQJIT::addAnyConvertExtern):
(JSC::Wasm::BBQJITImpl::BBQJIT::addExternConvertAny):
(JSC::Wasm::BBQJITImpl::BBQJIT::willParseOpcode):
(JSC::Wasm::BBQJITImpl::BBQJIT::didPopValueFromStack):
(JSC::Wasm::BBQJITImpl::BBQJIT::allocateWithHint):
(JSC::Wasm::BBQJITImpl::BBQJIT::consume):
* Source/JavaScriptCore/wasm/WasmBBQJIT.h:
* Source/JavaScriptCore/wasm/WasmBBQJIT32_64.cpp:
(JSC::Wasm::BBQJITImpl::BBQJIT::addTableGet):
(JSC::Wasm::BBQJITImpl::BBQJIT::addArrayNewFixed):
(JSC::Wasm::BBQJITImpl::BBQJIT::addArraySet):
(JSC::Wasm::BBQJITImpl::BBQJIT::addArrayFill):
(JSC::Wasm::BBQJITImpl::BBQJIT::addStructNewDefault):
(JSC::Wasm::BBQJITImpl::BBQJIT::addStructNew):
(JSC::Wasm::BBQJITImpl::BBQJIT::addStructSet):
(JSC::Wasm::BBQJITImpl::BBQJIT::addRefCast):
* Source/JavaScriptCore/wasm/WasmBBQJIT64.cpp:
(JSC::Wasm::BBQJITImpl::BBQJIT::addTableGet):
(JSC::Wasm::BBQJITImpl::BBQJIT::addArrayNew):
(JSC::Wasm::BBQJITImpl::BBQJIT::addArrayNewFixed):
(JSC::Wasm::BBQJITImpl::BBQJIT::addArraySet):
(JSC::Wasm::BBQJITImpl::BBQJIT::addArrayFill):
(JSC::Wasm::BBQJITImpl::BBQJIT::addStructNewDefault):
(JSC::Wasm::BBQJITImpl::BBQJIT::addStructNew):
(JSC::Wasm::BBQJITImpl::BBQJIT::addStructSet):
(JSC::Wasm::BBQJITImpl::BBQJIT::addRefCast):
(JSC::Wasm::BBQJITImpl::BBQJIT::addBranchNull):
(JSC::Wasm::BBQJITImpl::BBQJIT::addCallRef):
* Source/JavaScriptCore/wasm/WasmFunctionParser.h:
(JSC::Wasm::FunctionParser<Context>::parseExpression):
* Source/JavaScriptCore/wasm/WasmTypeDefinition.h:
(JSC::Wasm::isCompareOpType):
Canonical link: https://commits.webkit.org/283286.567@safari-7620-branch
Canonical link: https://commits.webkit.org/282416.440@webkitglib/2.46
Commit: 7228acc84b1d4fcbe5e569033c4325282912b20c
https://github.com/WebKit/WebKit/commit/7228acc84b1d4fcbe5e569033c4325282912b20c
Author: Yusuke Suzuki <ysuzuki at apple.com>
Date: 2025-01-30 (Thu, 30 Jan 2025)
Changed paths:
A JSTests/wasm/stress/very-large-wasm-gc-array-on-const-expr.js
M Source/JavaScriptCore/wasm/WasmConstExprGenerator.cpp
M Source/JavaScriptCore/wasm/WasmOperations.cpp
M Source/JavaScriptCore/wasm/WasmOperationsInlines.h
M Source/JavaScriptCore/wasm/WasmSlowPaths.cpp
Log Message:
-----------
Cherry-pick 285864 at main (b9bff032745c). https://bugs.webkit.org/show_bug.cgi?id=281959
[JSC] Correctly handle OOM wasm GC array
https://bugs.webkit.org/show_bug.cgi?id=281959
rdar://138494403
Reviewed by Yijia Huang and Keith Miller.
We are having places which are not handling OOM wasm GC arrays
correctly. This patch fixes them.
* JSTests/wasm/stress/very-large-wasm-gc-array-on-const-expr.js: Added.
* Source/JavaScriptCore/wasm/WasmConstExprGenerator.cpp:
(JSC::Wasm::ConstExprGenerator::createNewArray):
* Source/JavaScriptCore/wasm/WasmOperations.cpp:
(JSC::Wasm::JSC_DEFINE_NOEXCEPT_JIT_OPERATION):
* Source/JavaScriptCore/wasm/WasmOperationsInlines.h:
(JSC::Wasm::arrayNew):
(JSC::Wasm::arrayNewFixed):
* Source/JavaScriptCore/wasm/WasmSlowPaths.cpp:
(JSC::LLInt::WASM_SLOW_PATH_DECL):
Canonical link: https://commits.webkit.org/285864@main
Canonical link: https://commits.webkit.org/282416.441@webkitglib/2.46
Commit: 5354998c53b97cef3e9f726b4a104236f2f92366
https://github.com/WebKit/WebKit/commit/5354998c53b97cef3e9f726b4a104236f2f92366
Author: Yijia Huang <yijia_huang at apple.com>
Date: 2025-01-30 (Thu, 30 Jan 2025)
Changed paths:
M Source/JavaScriptCore/wasm/WasmOperationsInlines.h
Log Message:
-----------
Cherry-pick 283214 at main (0ebea356d54d). https://bugs.webkit.org/show_bug.cgi?id=279136
[WASM] Fix arrayNewElem with additional new element size check
https://bugs.webkit.org/show_bug.cgi?id=279136
rdar://134712862
Reviewed by Yusuke Suzuki.
When creating a new element array, we should check the new element size
against the maximum array size.
* Source/JavaScriptCore/wasm/WasmOperationsInlines.h:
(JSC::Wasm::arrayNewElem):
Canonical link: https://commits.webkit.org/283214@main
Canonical link: https://commits.webkit.org/282416.442@webkitglib/2.46
Commit: 6385ed48a6fc32fdaafbd5f7dfa54a9212da5988
https://github.com/WebKit/WebKit/commit/6385ed48a6fc32fdaafbd5f7dfa54a9212da5988
Author: Daniel Liu <daniel_liu4 at apple.com>
Date: 2025-01-30 (Thu, 30 Jan 2025)
Changed paths:
M Source/JavaScriptCore/wasm/WasmOperationsInlines.h
Log Message:
-----------
Cherry-pick 287691 at main (ba5c342c3a60). https://bugs.webkit.org/show_bug.cgi?id=283398
array.new_elem should check element segment before accessing type
https://bugs.webkit.org/show_bug.cgi?id=283398
rdar://140253586
Reviewed by Keith Miller and Yusuke Suzuki.
If we have an empty element segment, the type will be nullptr. However,
arrayNewElem does not check this before accessing its type, leading to
a segfault. This can be resolved by conditioning this path only if we
know the element is not empty.
* JSTests/wasm/stress/array-new-dropped-elem.js: Added.
* Source/JavaScriptCore/wasm/WasmOperationsInlines.h:
(JSC::Wasm::arrayNewElem):
Canonical link: https://commits.webkit.org/287691@main
Canonical link: https://commits.webkit.org/282416.443@webkitglib/2.46
Commit: 9c9519d4859cff611589faeb15169434fce3a9a9
https://github.com/WebKit/WebKit/commit/9c9519d4859cff611589faeb15169434fce3a9a9
Author: Yusuke Suzuki <ysuzuki at apple.com>
Date: 2025-01-30 (Thu, 30 Jan 2025)
Changed paths:
M Source/JavaScriptCore/wasm/WasmOperationsInlines.h
Log Message:
-----------
Cherry-pick 286463 at main (9335dacba16b). https://bugs.webkit.org/show_bug.cgi?id=282809
Aborted in JSC::Wasm::arrayNew
https://bugs.webkit.org/show_bug.cgi?id=282809
rdar://139502462
Reviewed by Yijia Huang.
This assertion is stale. ConstExprGenerator's implementation does not
guarantee that underlying 64bit value is always strict (not having
garbage on the other unused bits). And this assertion was added without
considering this fact. Just removing this, and it is fine.
* Source/JavaScriptCore/wasm/WasmOperationsInlines.h:
(JSC::Wasm::fillArray):
(JSC::Wasm::arrayNew):
Canonical link: https://commits.webkit.org/286463@main
Canonical link: https://commits.webkit.org/282416.444@webkitglib/2.46
Commit: b65ed4cdb768054bf4b1c36567dc97d7d6f85223
https://github.com/WebKit/WebKit/commit/b65ed4cdb768054bf4b1c36567dc97d7d6f85223
Author: Yusuke Suzuki <ysuzuki at apple.com>
Date: 2025-01-30 (Thu, 30 Jan 2025)
Changed paths:
A JSTests/wasm/stress/array-element-creation.js
A JSTests/wasm/stress/resources/array-element-creation.wasm
M Source/JavaScriptCore/wasm/WasmOperations.cpp
M Source/JavaScriptCore/wasm/WasmOperationsInlines.h
M Source/JavaScriptCore/wasm/js/JSWebAssemblyArray.cpp
M Source/JavaScriptCore/wasm/js/JSWebAssemblyArray.h
M Source/JavaScriptCore/wasm/js/JSWebAssemblyInstance.cpp
M Source/JavaScriptCore/wasm/js/JSWebAssemblyInstance.h
Log Message:
-----------
Cherry-pick 289530 at main (70ce977b3a9f). https://bugs.webkit.org/show_bug.cgi?id=285580
[JSC] WasmGC Array is broken for GC
https://bugs.webkit.org/show_bug.cgi?id=285580
rdar://141144921
Reviewed by Keith Miller.
WasmGC Array is broken for GC in multiple ways. We carefully reviewed WasmGC
Array implementation. We found many issues, and this patch fixes them.
1. Doing GC while putting GC values in FixedVector. That's totally
wrong. We fixed it by first creating WasmGC Array and modifying the
contents later.
2. arrayNewElem is always creating I64 array, which is broken. We should
create a specified typed array.
3. WasmGC Array copy implementation is using std::copy even for
overlapping region. That's totally wrong, and it should use memmove.
For GC-ref-types, we should use gcSafeMemmove.
* JSTests/wasm/stress/array-element-creation.js: Added.
* JSTests/wasm/stress/resources/array-element-creation.wasm: Added.
* Source/JavaScriptCore/wasm/WasmOperations.cpp:
(JSC::Wasm::JSC_DEFINE_NOEXCEPT_JIT_OPERATION):
* Source/JavaScriptCore/wasm/WasmOperationsInlines.h:
(JSC::Wasm::fillArray):
(JSC::Wasm::arrayNew):
(JSC::Wasm::copyElementsInReverse):
(JSC::Wasm::arrayNewFixed):
(JSC::Wasm::createArrayFromDataSegment):
(JSC::Wasm::arrayNewData):
(JSC::Wasm::arrayNewElem):
(JSC::Wasm::arrayInitElem):
(JSC::Wasm::arrayInitData):
(JSC::Wasm::createArrayValue): Deleted.
(JSC::Wasm::createArrayFromElementSegment): Deleted.
* Source/JavaScriptCore/wasm/js/JSWebAssemblyArray.cpp:
(JSC::JSWebAssemblyArray::JSWebAssemblyArray):
(JSC::JSWebAssemblyArray::fill):
(JSC::JSWebAssemblyArray::copy):
(JSC::JSWebAssemblyArray::visitChildrenImpl):
* Source/JavaScriptCore/wasm/js/JSWebAssemblyArray.h:
* Source/JavaScriptCore/wasm/js/JSWebAssemblyInstance.cpp:
(JSC::JSWebAssemblyInstance::copyDataSegment):
(JSC::JSWebAssemblyInstance::copyElementSegment):
* Source/JavaScriptCore/wasm/js/JSWebAssemblyInstance.h:
Originally-landed-as: ac2bd207812a. rdar://143529972
Canonical link: https://commits.webkit.org/289530@main
Canonical link: https://commits.webkit.org/282416.445@webkitglib/2.46
Compare: https://github.com/WebKit/WebKit/compare/7a89c82ae241...b65ed4cdb768
To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications
More information about the webkit-changes
mailing list