Branch: refs/heads/webkitglib/2.52
Home: https://github.com/WebKit/WebKit
Commit: 1551df23181febd0ba15a2533234a5f28ec0cd4e
https://github.com/WebKit/WebKit/commit/1551df23181febd0ba15a2533234a5f28ec0cd4e
Author: Mark Lam <[email protected]>
Date: 2026-09-08 (Tue, 08 Sep 2026)
Changed paths:
A JSTests/stress/unlinked-metadata-table-finalize-overflow.js
M Source/JavaScriptCore/bytecode/UnlinkedCodeBlockGenerator.cpp
M Source/JavaScriptCore/bytecode/UnlinkedCodeBlockGenerator.h
M Source/JavaScriptCore/bytecode/UnlinkedMetadataTable.cpp
M Source/JavaScriptCore/bytecode/UnlinkedMetadataTable.h
M Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp
Log Message:
-----------
Cherry-pick [email protected] (9343a9521f58).
https://bugs.webkit.org/show_bug.cgi?id=317632
Handle overflows in UnlinkedMetadataTable::finalize().
https://bugs.webkit.org/show_bug.cgi?id=317632
rdar://172794625
Reviewed by Dan Hecht.
If the number of opcodes (with metadata of substantive size) is large, the
32-bit unsigned
computed buffer offsets in UnlinkedMetadataTable::finalize() can overflow.
This patch
applies the use of CheckedArithmetic to detect and handle any potential
overflows. In the
event of a detected overflow, we'll propagate the failure to allocate the
bytecode metadata
up to the BytecodeGenerator, and treat its as an OOM error during parsing.
Test: JSTests/stress/unlinked-metadata-table-finalize-overflow.js
* JSTests/stress/unlinked-metadata-table-finalize-overflow.js: Added.
(try.f):
(catch):
* Source/JavaScriptCore/bytecode/UnlinkedCodeBlockGenerator.cpp:
(JSC::UnlinkedCodeBlockGenerator::finalize):
* Source/JavaScriptCore/bytecode/UnlinkedCodeBlockGenerator.h:
* Source/JavaScriptCore/bytecode/UnlinkedMetadataTable.cpp:
(JSC::UnlinkedMetadataTable::finalize):
* Source/JavaScriptCore/bytecode/UnlinkedMetadataTable.h:
* Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::generate):
Identifier: [email protected]
Canonical link: https://commits.webkit.org/305877.1165@webkitglib/2.52
Commit: f0619742772d434d18596148fa75300e84d4ffdd
https://github.com/WebKit/WebKit/commit/f0619742772d434d18596148fa75300e84d4ffdd
Author: Keith Miller <[email protected]>
Date: 2026-09-08 (Tue, 08 Sep 2026)
Changed paths:
A JSTests/wasm/stress/tail-call-unused-pins.js
M Source/JavaScriptCore/jit/AssemblyHelpers.cpp
M Source/JavaScriptCore/jit/AssemblyHelpers.h
M Source/JavaScriptCore/wasm/WasmOMGIRGenerator.cpp
Log Message:
-----------
Cherry-pick [email protected] (654718255548).
https://bugs.webkit.org/show_bug.cgi?id=317654
[Wasm] Exclude wasmBoundsCheckingSizeRegister from the callee saves restored
https://bugs.webkit.org/show_bug.cgi?id=317654
rdar://177693309
Reviewed by Yijia Huang.
GPRInfo::wasmBoundsCheckingSizeRegister (callee save) is only pinned in B3
when
the OMG callee is compiled for MemoryMode::BoundsChecking. In Signaling mode
it stays in B3/Air's mutable register set, and createTailCallPatchpoint
declares the full callee-save set as clobberEarly so that B3 does not place
an input there before the tail-call's parallel move runs. That clobberEarly
causes AirHandleCalleeSaves to include regCS4 in the function's
calleeSaveRegisterAtOffsetList(). The OMG prologue saves
wasmBoundsCheckingSizeRegister to the callee save list and when making a
tail call that callee save is restored after the callee's memory bounds
are set.
The wasm ABI already treats the pinned registers as effectively caller-save
across wasm-to-wasm calls. Tail calls do not restore them either. Restoring
wasmBoundsCheckingSizeRegister to the prologue-saved caller value in
prepareForTailCallImpl is therefore unnecessary.
This patch teaches emitRestoreCalleeSavesFor to take a dontRestoreRegisters
set and uses it from prepareForTailCallImpl to skip
wasmBoundsCheckingSizeRegister. I also added a FIXME at the pinRegister
site noting that wasmBoundsCheckingSizeRegister is effectively caller-save
in the wasm ABI.
Identifier: [email protected]
Canonical link: https://commits.webkit.org/305877.1166@webkitglib/2.52
Commit: 958472e57ad79a9b12f2f6618b753edfc06fdf43
https://github.com/WebKit/WebKit/commit/958472e57ad79a9b12f2f6618b753edfc06fdf43
Author: Said Abou-Hallawa <[email protected]>
Date: 2026-09-08 (Tue, 08 Sep 2026)
Changed paths:
M Source/WebCore/platform/graphics/PixelBufferConversion.cpp
Log Message:
-----------
Cherry-pick [email protected] (e66d0b93bf1f).
https://bugs.webkit.org/show_bug.cgi?id=316131
Converting Float16 pixels buffers to Unpremultiplied or premultiplied may
miss the last row
https://bugs.webkit.org/show_bug.cgi?id=316131
rdar://177764433
Reviewed by Gerald Squelart.
convertImagePixelsFromFloat16ToFloat16() was written with the wrong
assumption.
The calculations in this function assume the source and destination
PixelBuffers
are rectangular. But sometimes they are not.
ImageBufferBackend::getPixelBuffer()
and ImageBufferBackend::putPixelBuffer() get subspans from the source and
destination PixelBuffers starting from the starting point till the end of
these
PixelBuffers. The bytesPerRow of the PixelBuffer and
PixelBufferConversionView
may be larger than the bytesPerRow of the requested PixelBuffer.
Like what other conversion functions do, the solution is not to drive the
width
and the height of sourceBuffer and destinationBuffer from the size_bytes
and the
bytesPerRow. The fix is to convert destinationBytesPerRow pixels from the
sourceBuffer into the destinationBuffer for every row. To get the starting
pixel
for the next row from the sourceBuffer, we need to move by
sourceBytesPerRow.
* Source/WebCore/platform/graphics/PixelBufferConversion.cpp:
(WebCore::convertImagePixelsFromFloat16ToFloat16):
Identifier: [email protected]
Canonical link: https://commits.webkit.org/305877.1167@webkitglib/2.52
Compare: https://github.com/WebKit/WebKit/compare/c17624be2818...958472e57ad7
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
