246 proposed backports#1697
Open
justinmichaud wants to merge 54 commits into
Open
Conversation
https://bugs.webkit.org/show_bug.cgi?id=280881 Reviewed by Nikolas Zimmermann and Adrian Perez de Castro. The option -fdebug-types-section causes ld to OOM when using gcc on armv7. Do not use it for armv7. * Source/cmake/WebKitCompilerFlags.cmake: Canonical link: https://commits.webkit.org/284678@main (cherry picked from commit 799d993)
https://bugs.webkit.org/show_bug.cgi?id=280882 Reviewed by Justin Michaud. GCC will complain about differing alignment requirements when casting a 4-byte element span to a 8-byte element span on ARMv7. (Causing the build to fail.) Muffle that warning. * Source/WTF/wtf/StdLibExtras.h: Canonical link: https://commits.webkit.org/284837@main (cherry picked from commit 19cbafd)
https://bugs.webkit.org/show_bug.cgi?id=288126 Reviewed by Yusuke Suzuki. Set callee tag in wasm_to_js_wrapper_entry on armv7, like its JITed counterpart WasmToJS.cpp:wasmToJS * Source/JavaScriptCore/llint/WebAssembly.asm: Canonical link: https://commits.webkit.org/291057@main (cherry picked from commit 7c2a5ba)
https://bugs.webkit.org/show_bug.cgi?id=282490 Reviewed by Yusuke Suzuki and Justin Michaud. Contrary to the -O1 and -O2 register allocators, AirAllocateRegistersAndStackAndGenerateCode.cpp calls lowerStackArgs() first and then does register allocation and code generation in a single pass. In that file, callFrameAddr uses the extendedOffsetAddrRegister() as a scratch register in order to access FP/SP offsets that are too wide for an immediate offset. However, extendedOffsetAddrRegister() may be live, since it's also used by lowerStackArgs(). This trivially crashes testCallFunctionWithHellaArguments3 on ARMv7, but a slightly modified version of this test will also crash on ARM64. Specifically, this commit modifies testCallFunctionWithHellaArguments3 to use a number of constant values that are not representable as immediates on ARM64 (otherwise they become Imm Air::Args), resulting in a crashing test at O0. This doesn't affect the other register allocators, as they spill registers by means of Arg::stack() and only later lowerStackArgs() to handle these. We fix this by naively spilling (and immediately reloading) extendedOffsetAddrRegister() whenever we need to use it to access a wide offset in callFrameAddr(). With the fix in place, this patch switches ARMv7 to use the same code paths as ARM64 for handling Air::Args with a wide offset. * Source/JavaScriptCore/b3/B3Common.cpp: (JSC::B3::extendedOffsetAddrRegister): * Source/JavaScriptCore/b3/air/AirAllocateRegistersAndStackAndGenerateCode.cpp: (JSC::B3::Air::GenerateAndAllocateRegisters::callFrameAddr): (JSC::B3::Air::GenerateAndAllocateRegisters::withCallFrameAddr): (JSC::B3::Air::GenerateAndAllocateRegisters::flush): (JSC::B3::Air::GenerateAndAllocateRegisters::alloc): (JSC::B3::Air::GenerateAndAllocateRegisters::prepareForGeneration): (JSC::B3::Air::GenerateAndAllocateRegisters::generate): (JSC::B3::Air::callFrameAddr): Deleted. * Source/JavaScriptCore/b3/air/AirAllocateRegistersAndStackAndGenerateCode.h: * Source/JavaScriptCore/b3/air/AirCode.cpp: (JSC::B3::Air::Code::Code): * Source/JavaScriptCore/b3/air/AirLowerStackArgs.cpp: (JSC::B3::Air::lowerStackArgs): * Source/JavaScriptCore/b3/testb3_5.cpp: (JSC_DEFINE_NOEXCEPT_JIT_OPERATION): (testCallFunctionWithHellaArguments3): Canonical link: https://commits.webkit.org/291111@main (cherry picked from commit 2dfc93f)
https://bugs.webkit.org/show_bug.cgi?id=288081 Reviewed by Yusuke Suzuki and Justin Michaud. Properly allocate a scratch FPR instead of a GPR pair for a scratch float value. * Source/JavaScriptCore/wasm/WasmBBQJIT32_64.cpp: (JSC::Wasm::BBQJITImpl::BBQJIT::addF64Copysign): Canonical link: https://commits.webkit.org/291216@main (cherry picked from commit 667960f)
https://bugs.webkit.org/show_bug.cgi?id=288574 Reviewed by Michael Catanzaro. This change was tested with a JSCOnly build in an armhf webkit-container-sdk container on an ARM64 Thelio Astra workstation. * Source/cmake/WebKitCommon.cmake: * Tools/Scripts/webkitdirs.pm: (generateBuildSystemFromCMakeProject): Canonical link: https://commits.webkit.org/291253@main (cherry picked from commit 4a09da2)
https://bugs.webkit.org/show_bug.cgi?id=289157 Reviewed by Yusuke Suzuki. Avoids integer overflow when multiplying by ramSize. * Source/JavaScriptCore/heap/CompleteSubspace.cpp: (JSC::CompleteSubspace::tryAllocateSlow): Canonical link: https://commits.webkit.org/291887@main (cherry picked from commit 47b01a3)
https://bugs.webkit.org/show_bug.cgi?id=288079 Reviewed by Yusuke Suzuki and Justin Michaud. Compute required alignment in a platform independent way at compile time using constexpr. * Source/JavaScriptCore/yarr/YarrInterpreter.cpp: (JSC::Yarr::Interpreter::DisjunctionContext::allocationSize): (JSC::Yarr::Interpreter::ParenthesesDisjunctionContext::allocationSize): Canonical link: https://commits.webkit.org/291952@main (cherry picked from commit 6040dcd)
https://bugs.webkit.org/show_bug.cgi?id=289585 Reviewed by Yusuke Suzuki. We missed storing a tag for the callee's callee. The JIT version of this stub uses storeCell. * Source/JavaScriptCore/wasm/WasmOperations.cpp: (JSC::Wasm::JSC_DEFINE_JIT_OPERATION): Canonical link: https://commits.webkit.org/292019@main (cherry picked from commit a9bf19a)
https://bugs.webkit.org/show_bug.cgi?id=288083 Reviewed by Yusuke Suzuki and Justin Michaud. On armv7 certain uses of branchPtr cause it to clobber its own arguments, leading to bogus assembly. Catch this pitfall at least in debug builds and fix instances of this bug. * Source/JavaScriptCore/assembler/MacroAssemblerARMv7.h: (JSC::MacroAssemblerARMv7::branch32): * Source/JavaScriptCore/bytecode/InlineCacheCompiler.cpp: (JSC::InlineCacheCompiler::compile): * Source/JavaScriptCore/wasm/WasmBBQJIT.cpp: (JSC::Wasm::BBQJITImpl::BBQJIT::addLoopOSREntrypoint): Canonical link: https://commits.webkit.org/292608@main (cherry picked from commit 42c1414)
https://bugs.webkit.org/show_bug.cgi?id=290259 Reviewed by Adrian Perez de Castro. /home/thomas/br-test-pkg/bootlin-armv7-glibc/build/webkitgtk-2.48.0/Source/WebCore/loader/ResourceLoadInfo.cpp:88:32: error: ‘TextTrackResource’ is not a member of ‘WebCore::CachedResource::Type’ 88 | case CachedResource::Type::TextTrackResource: | ^~~~~~~~~~~~~~~~~ Commit WebKit/WebKit@951a118 "Fix missing includes and guards when certain features are disabled", added guards to TextTrackResource in CachedResource, but forgot to add this one. Signed-off-by: Thomas Devoogdt <thomas@devoogdt.com> Canonical link: https://commits.webkit.org/292680@main (cherry picked from commit 120eef4)
https://bugs.webkit.org/show_bug.cgi?id=293629 Reviewed by Yusuke Suzuki. It is super difficult to track alignment when branch compaction might shift instructions by 2 bytes. This makes it easy to tear writes to the jit region, so let's just skip it for now in those cases. * Source/JavaScriptCore/assembler/ARMv7Assembler.h: (JSC::ARMv7Assembler::computeJumpType): Canonical link: https://commits.webkit.org/295468@main (cherry picked from commit 432f625)
https://bugs.webkit.org/show_bug.cgi?id=295498 Reviewed by Justin Michaud. WASM BBQJIT on 32-bit uses wasmScratchGPR when loading F32/F64 constants, causing segmentation faults in JetStream3's tfjs-wasm. The issue occurs when emitCheckAndPrepareAndMaterializePointerApply stores a memory address in wasmScratchGPR, then passes it to a functor. If the functor loads a floating-point constant, it overwrites wasmScratchGPR, corrupting the address and causing null pointer access. This patch fixes by using MacroAssembler's move32ToFloat and move64ToDouble directly with immediate values, eliminating the use of wasmScratchGPR. * Source/JavaScriptCore/wasm/WasmBBQJIT32_64.cpp: (JSC::Wasm::BBQJITImpl::BBQJIT::emitMoveConst): Canonical link: https://commits.webkit.org/297169@main (cherry picked from commit 93a792f)
https://bugs.webkit.org/show_bug.cgi?id=295724 Reviewed by Sosuke Suzuki. On ARMv7, we cannot store atomically to unaligned addresses. On other platforms, this patch should be a no-op, but it aligns some patchable places for ARMv7. A follow-up patch will change the way we do patching. Canonical link: https://commits.webkit.org/297343@main (cherry picked from commit f652173)
https://bugs.webkit.org/show_bug.cgi?id=296221 Reviewed by Sosuke Suzuki. This should be a no-op on other platforms, but it makes sure extra padding won't confuse the repatching logic. Canonical link: https://commits.webkit.org/297678@main (cherry picked from commit 8d0d636)
https://bugs.webkit.org/show_bug.cgi?id=294597 Reviewed by Justin Michaud. ARMv7 can't rely on BUILTIN_FRAME_ADDRESS (it's broken on GCC). Properly initialize temporaryCallFrame in WebAssembly.asm. This should really be `or (not USE_BUILTIN_FRAME_ADDRESS)`, but we need to keep the number of configuration values down to avoid a combinatorial explosion in the size of LLIntAssembly.h. When we have a fix for GCC, we can just drop the reliance on temporaryCallFrame, but in the meantime this avoids flaky tests in EWS. * Source/JavaScriptCore/llint/WebAssembly.asm: Canonical link: https://commits.webkit.org/298095@main (cherry picked from commit fe797d6)
https://bugs.webkit.org/show_bug.cgi?id=293694 Reviewed by Yusuke Suzuki and Sosuke Suzuki. Not all armv7 chips are required to suport unaligned strd instructions. For example, my Neoverse N1 does not support it. This is documented at https://developer.arm.com/documentation/100748/0624/Alignment-support-in-Arm-Compiler-for-Embedded-6/Aligned-and-unaligned-accesses. We should remove these lowerings to support all armv7 processors. In the future, we may want to add them back when we can handle the alignment check separately. * Source/JavaScriptCore/assembler/MacroAssemblerARMv7.h: (JSC::MacroAssemblerARMv7::storePair32): Canonical link: https://commits.webkit.org/298097@main (cherry picked from commit 5e20020)
https://bugs.webkit.org/show_bug.cgi?id=298046 Reviewed by Justin Michaud. The program import-mutable-global.js generates the following in armv7: 1. if shift is zero jump to end 2. if shift is less than 32 do: 2.1 spill r0, r1 to use as scratch 2.2 do the shift ... 4. end however, if we take shift is zero and we jump to end, BBQ still thinks we did the spill and reloads r0, r1, loading garbage. This PR fixes the issue by doing the spill as soon as we enter the function, so we always reload the right values. * Source/JavaScriptCore/wasm/WasmBBQJIT32_64.cpp: (JSC::Wasm::BBQJITImpl::BBQJIT::shiftI64Helper): Canonical link: https://commits.webkit.org/299328@main (cherry picked from commit e4f7416dd860af0af66f3a0a3ce8c10ad5c5ee8d)
https://bugs.webkit.org/show_bug.cgi?id=298390 Reviewed by Adrian Perez de Castro. LLD runs out of address space when trying to link on 32-bits. Opt out of using it when that's the case, at least for ARMv7. Canonical link: https://commits.webkit.org/299619@main (cherry picked from commit 741df3fb836f6f6148c9bef4d53b168c14552309)
https://bugs.webkit.org/show_bug.cgi?id=299515 Reviewed by Yusuke Suzuki. On ARMv7, the least significant bit in the link register indicates the mode (ARM/Thumb) of the code that we return to. Callers of preserveReturnAddressAfterCall care about the return address and when calling the throwExceptionFromOMGThunk (as introduced in 300298@main) the LSB being set results in a return address outside the function, whose CallSiteIndex can therefore not be looked up. Simply clear the LSB when preserving the return address on ARMv7. Canonical link: https://commits.webkit.org/300555@main (cherry picked from commit 4d672bf7ca92bcdf9ceac15576d4443c36343476)
https://bugs.webkit.org/show_bug.cgi?id=300217 Reviewed by Adrian Perez de Castro. Add "-mthumb" flag to GCC to enable compiling thumb2 instruction set if supported. * Source/cmake/OptionsCommon.cmake: Canonical link: https://commits.webkit.org/301124@main (cherry picked from commit 5528017994db81391afaba90dc2c1909d1d8842f)
https://bugs.webkit.org/show_bug.cgi?id=300509 Reviewed by Justin Michaud. In shiftI64Helper, we would check if the shift amount was zero and just jump to the end, without moving the lhs to the result. No new tests, but this was found when analysing the crash in JetStream3's tfjs-wasm.js. 32-bit JSC still crashes when running that test but this gets us a little bit further. * Source/JavaScriptCore/wasm/WasmBBQJIT32_64.cpp: (JSC::Wasm::BBQJITImpl::BBQJIT::shiftI64Helper): Canonical link: https://commits.webkit.org/301475@main (cherry picked from commit 3fcedc7fe6c82ffdda06219e621b38dda67bdf58)
https://bugs.webkit.org/show_bug.cgi?id=300707 Reviewed by Justin Michaud. r3 was missing from the list of registers being saved before the print call. * Source/JavaScriptCore/assembler/MacroAssemblerARMv7.cpp: (JSC::MacroAssembler::probe): Canonical link: https://commits.webkit.org/301546@main (cherry picked from commit 44ac40fabf2f69513ed206b8787356612f8874eb)
https://bugs.webkit.org/show_bug.cgi?id=301350 Reviewed by Justin Michaud. This is convenient to be able to run the tests after cross-building for ARMv7 on an aarch64 box that can natively run ARMv7 binaries. Canonical link: https://commits.webkit.org/302076@main (cherry picked from commit 0713bc1a8923961b69ba02d84239754647c0c141)
https://bugs.webkit.org/show_bug.cgi?id=301931 Reviewed by Justin Michaud. When running JS3 I noticed the following code: [ 0x22d] I64Or 0xf1b953fa: orr.w r1, r2, r4 0xf1b953fe: orr.w r0, r1, r3 Here, lhs is (r1, r2), rhs is (r3, r4) and result is (r0, r1), so when we write to resultHi (r1), we override the value in lhs, then read it again in the second orr, leading to a wrong result. This patch implements i64or in the ARMv7 backend and fixes this problem by calculating the low or to a scratch, calculating hi to the destination, then moving the low or from the scratch to the destination. * Source/JavaScriptCore/assembler/MacroAssemblerARMv7.h: (JSC::MacroAssemblerARMv7::or64): * Source/JavaScriptCore/wasm/WasmBBQJIT32_64.cpp: (JSC::Wasm::BBQJITImpl::BBQJIT::addI64Or): Canonical link: https://commits.webkit.org/302862@main (cherry picked from commit c977165dfa4c852c7b6b029d8fc7be710cebd8a3)
… is also a destination https://bugs.webkit.org/show_bug.cgi?id=302469 Reviewed by Justin Michaud. This patch expands a ldrd into a pair of ldr if any of the destination registers is also the register holding the memory address. Before: 0xf1502462: ldrd r0, r1, [r0] After: 0xf1502462: ldr r1, [r0, WebPlatformForEmbedded#4] 0xf1502464: ldr r0, [r0] * Source/JavaScriptCore/assembler/MacroAssemblerARMv7.h: (JSC::MacroAssemblerARMv7::loadPair32): Canonical link: https://commits.webkit.org/303043@main (cherry picked from commit 93ba069cf1bab91677362638030f126820ef373a)
…ration https://bugs.webkit.org/show_bug.cgi?id=302016 Reviewed by Justin Michaud. This PR replace IT blocks with branchless instruction sequences for common test32 and compare32 operations. This PR also removes NOPs in conditional moves via condition inversions, and adds assertions for invalid Carry/Overflow conditions (tst doesn't set these flags). * Source/JavaScriptCore/assembler/MacroAssemblerARMv7.h: (JSC::MacroAssemblerARMv7::invert): (JSC::MacroAssemblerARMv7::commuteCompareToZeroIntoTest): (JSC::MacroAssemblerARMv7::branch32): (JSC::MacroAssemblerARMv7::compare32): (JSC::MacroAssemblerARMv7::test32): (JSC::MacroAssemblerARMv7::moveConditionally32): (JSC::MacroAssemblerARMv7::moveConditionallyTest32): (JSC::MacroAssemblerARMv7::moveDoubleConditionally32): (JSC::MacroAssemblerARMv7::moveDoubleConditionallyTest32): (JSC::MacroAssemblerARMv7::moveDoubleOrNop): Deleted. (JSC::MacroAssemblerARMv7::moveOrNop): Deleted. Canonical link: https://commits.webkit.org/303329@main (cherry picked from commit 3baaaee049d934750e4ac547eb41a2d3eb421df1)
…n loading cells. https://bugs.webkit.org/show_bug.cgi?id=305427 Reviewed by Yusuke Suzuki. Patch by @emutavchi downstream: WebPlatformForEmbedded#1593. We find ourselves in a state where canLoad says yes, because our JSValue can be loaded via FPR, but we choose to load it via GPR instead because we do not have two gprs free. This inconsistency causes an assertion failure, and incorrect tail call shuffling. This can only happen if loadsIntoFPR is true, but loadsIntoGPR is false. In addition, everything DisplacedInJSStack must either have loadsIntoFPR or loadsIntoGPR, so no other corner cases need to be considered. Canonical link: https://commits.webkit.org/305572@main (cherry picked from commit 9cc23c0e75b77974539bcb414eacef33bf94ed02)
https://bugs.webkit.org/show_bug.cgi?id=315241 <rdar://problem/177567563> Reviewed by Adrian Perez de Castro. I saw this build race in EWS on jsc-armv7. * Source/JavaScriptCore/CMakeLists.txt: Make JavaScriptCoreSharedScripts depend on JSCBuiltins. Both depend on the same generated .py files in ${JavaScriptCore_SCRIPTS_DIR}. A parallel Make build can race two `cmake -E copy_if_different` invocations on the same destination — leaving a half-written .py. Canonical link: https://commits.webkit.org/313660@main (cherry picked from commit 3d4cdae16665cf3a34135e31a9c2e97eb52e5592)
https://bugs.webkit.org/show_bug.cgi?id=288554 rdar://144072285 Reviewed by Yusuke Suzuki. CodeBlock's StubInfo can keep watchpoints alive which do not ref data they hold, meaning that when the CodeBlock is jettisoned, we may have dangling pointers to data that was freed during a GC. * Source/JavaScriptCore/bytecode/CodeBlock.cpp: (JSC::CodeBlock::jettison): Originally-landed-as: 289651.190@safari-7621-branch (15053072f223). rdar://148056646 Canonical link: https://commits.webkit.org/293230@main (cherry picked from commit 3f23dc5)
https://bugs.webkit.org/show_bug.cgi?id=287567 rdar://144076957 Reviewed by Yijia Huang and Yusuke Suzuki. GetByIdModeMetadata does not reset its structure ID upon transitioning to ArrayLengthMode, meaning that this could get held over across another reset. This could later cause access to a freed (or reallocated) structure ID. This patch also cleans up the code in `setProtoLoadMode` slightly to clear up the specific writes being performed. This does not apply to other modes, since they set their structure ID explicitly. Since the mutator thread is the thread changing modes, it will only invalidate the structure ID after the call to clearToDefaultModeWithoutCache finishes, meaning that the structure ID already is cleared. * Source/JavaScriptCore/bytecode/GetByIdMetadata.h: (JSC::GetByIdModeMetadata::clearToDefaultModeWithoutCache): (JSC::GetByIdModeMetadata::setUnsetMode): (JSC::GetByIdModeMetadata::setArrayLengthMode): (JSC::GetByIdModeMetadata::setProtoLoadMode): * Source/JavaScriptCore/bytecode/GetByStatus.cpp: (JSC::GetByStatus::computeFromLLInt): Originally-landed-as: 289651.165@safari-7621-branch (a93595279e2b). rdar://148058163 Canonical link: https://commits.webkit.org/293257@main (cherry picked from commit 78b9637)
https://bugs.webkit.org/show_bug.cgi?id=294420 rdar://153246940 Reviewed by Keith Miller. Let's make CodeBlock jettisoning a bit safer. Regardless of the type of CodeBlock, when it is getting jettisoning, ensuring unlinking it from CallLinkInfo is fine. * Source/JavaScriptCore/bytecode/CodeBlock.cpp: (JSC::CodeBlock::jettison): Canonical link: https://commits.webkit.org/296207@main (cherry picked from commit 9629942)
https://bugs.webkit.org/show_bug.cgi?id=298236 rdar://157587352 Reviewed by Keith Miller. Before this change, DoublyLinkedList leaves the next/prev pointers in a dangling state when removing a node from the list. Then, if the node is re-added, the next/prev pointers are reset when necessary. Let's make a stronger invariant: if the node is not in the list, then the prev/next pointers are nullptr. (Note that the converse is not true for single element lists.) Then, add some asserts to verify the WeakSet's WeakBlock list lifecycle to try to help track down a mysterious crash. The WeakBlock ownership can be transferred from the WeakSet to the Heap, at which point the prev/next should be nulled out and, after this change, no longer dangling. Bonus: remove MarkedSpace::freeOrShrinkBlock() since it's never called. Canonical link: https://commits.webkit.org/299454@main (cherry picked from commit c90e64eec92dad9dfa49801778997c6e449ce1c6)
…g on 32 bits. https://bugs.webkit.org/show_bug.cgi?id=293720 Reviewed by Yusuke Suzuki. On 32-bit armv7/linux we run into an issue where the environment strings located at the bottom of the stack, as well as some random bits inside the libc portion of the stack are interpreted as cells pointing into the heap, keeping actually dead objects alive. Yusuke previously attempted to fix this by excluding environ and before, but there are additional fake roots only a few hundred bytes below that. This patch excludes the caller of main entirely. * Source/JavaScriptCore/jsc.cpp: (jscmain): * Source/JavaScriptCore/runtime/JSLock.cpp: (JSC::JSLock::didAcquireLock): * Source/WTF/wtf/StackBounds.cpp: (WTF::StackBounds::setBottomOfMainThreadMain): (WTF::StackBounds::currentThreadStackBoundsInternal): * Source/WTF/wtf/StackBounds.h: (WTF::StackBounds::checkConsistency const): * Source/WebKit/WebProcess/gtk/WebProcessMainGtk.cpp: (WebKit::WebProcessMain): * Source/WebKit/WebProcess/wpe/WebProcessMainWPE.cpp: (WebKit::WebProcessMain): (cherry picked from commit 0f53210)
https://bugs.webkit.org/show_bug.cgi?id=278646 Reviewed by Eric Carlson. Just clamp the value to avoid negative numbers when seeking. Also return in GStreamer ports infinity as maxTimeSeekable for live streams. Test: imported/w3c/web-platform-tests/html/semantics/embedded-content/media-elements/seeking/seek-to-negative-time.htm Also another bunch of tests have now corrected expectations. * LayoutTests/imported/w3c/web-platform-tests/html/semantics/embedded-content/media-elements/seeking/seek-to-currentTime-expected.txt: * LayoutTests/imported/w3c/web-platform-tests/html/semantics/embedded-content/media-elements/seeking/seek-to-negative-time-expected.txt: * LayoutTests/platform/glib/TestExpectations: * LayoutTests/platform/glib/imported/w3c/web-platform-tests/html/semantics/embedded-content/media-elements/audio_loop_seek_to_eos-expected.txt: * LayoutTests/platform/glib/imported/w3c/web-platform-tests/html/semantics/embedded-content/media-elements/seeking/seek-to-negative-time-expected.txt: Removed. * LayoutTests/platform/glib/imported/w3c/web-platform-tests/html/semantics/embedded-content/media-elements/video_loop_base-expected.txt: * Source/WebCore/html/HTMLMediaElement.cpp: (WebCore::HTMLMediaElement::setCurrentTimeForBindings): * Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp: (WebCore::MediaPlayerPrivateGStreamer::maxTimeSeekable const): Canonical link: https://commits.webkit.org/283134@main (cherry picked from commit 081be27)
https://bugs.webkit.org/show_bug.cgi?id=279055 Reviewed by Xabier Rodriguez-Calvar. HTMLMediaElement fires 'timeupdate' every 250ms in repeating timer. If the timer is fired before 250ms from the last occurrence, it is silently skipped and needs to wait for another 250ms. As a result, the gap between two following timeupdate events may vary 250-500ms. This may happen in two cases: 1) Non-periodic timeupdate event is scheduled for any reason. 2) When the difference between two timer calls is lower than 250ms. This may happen when there are multiple timers to handle at the same time in ThreadTimers (maxDurationOfFiringTimers). Original author: Andrzej Surdej <Andrzej_Surdej@comcast.com> See: WebPlatformForEmbedded#1392 * Source/WebCore/html/HTMLMediaElement.cpp: (WebCore::HTMLMediaElement::scheduleTimeupdateEvent): Schedule next event on the remaining time difference so that maxTimeupdateEventFrequency is honored, instead of waiting a full cycle. Canonical link: https://commits.webkit.org/283264@main (cherry picked from commit fb9b613)
https://bugs.webkit.org/show_bug.cgi?id=285835 Reviewed by Adrian Perez de Castro. And not the size already set in the main thread. * Source/WebKit/WebProcess/WebPage/libwpe/AcceleratedSurfaceLibWPE.cpp: (WebKit::AcceleratedSurfaceLibWPE::clientResize): Canonical link: https://commits.webkit.org/288798@main (cherry picked from commit b297321)
https://bugs.webkit.org/show_bug.cgi?id=296690 Reviewed by Philippe Normand. OpenCDM/Thunder can answer with a null message when loading a wrong session. We need to deal with that. * Source/WebCore/platform/graphics/gstreamer/eme/CDMThunder.cpp: (WebCore::CDMInstanceSessionThunder::loadSession): Canonical link: https://commits.webkit.org/298032@main (cherry picked from commit 386dfe0)
… pointer https://bugs.webkit.org/show_bug.cgi?id=289017 rdar://145852436 Reviewed by Mark Lam. On environment having 32bit pointer or non-little-endian, mode needs to be set. * Source/JavaScriptCore/bytecode/GetByIdMetadata.h: (JSC::GetByIdModeMetadata::setProtoLoadMode): Originally-landed-as: 289651.211@safari-7621-branch (38a19eb3b7c0). rdar://148052940 Canonical link: https://commits.webkit.org/293387@main (cherry picked from commit ae20fca)
…nZero with distinct registers Regressed by the branchless test32/compare32 codegen change (bug 302016, 303329@main): the register-register test32 overload emitted the compare32 equality idiom (eor+clz+lsr, computing op1 == op2) for the Zero/NonZero result conditions, where test32 semantics require (op1 & op2) == 0. The same-register and immediate-mask forms were correct, so JS tiers never exposed it; OMG's fused i32.eqz(i32.and(a, b)) materializes Test32 with distinct registers and produced inverted flag logic (8bitbench-wasm state corruption / browser JetStream3 stalls on ARMv7). Also applies upstream: 303329@main carries the same latent bug. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
https://bugs.webkit.org/show_bug.cgi?id=286679 rdar://143819751 Unreviewed, revert. * JSTests/wasm/stress/tail-call-simple-i64.js: Removed. * Source/JavaScriptCore/assembler/MacroAssemblerARMv7.h: (JSC::MacroAssemblerARMv7::transfer64): Deleted. * Source/JavaScriptCore/b3/B3LowerToAir.cpp: * Source/JavaScriptCore/b3/B3LowerToAir32_64.cpp: * Source/JavaScriptCore/b3/B3MoveConstants.cpp: * Source/JavaScriptCore/b3/air/AirCustom.h: (JSC::B3::Air::WasmBoundsCheckCustom::forEachArg): * Source/JavaScriptCore/disassembler/CapstoneDisassembler.cpp: * Source/JavaScriptCore/jit/Width.h: * Source/JavaScriptCore/runtime/JSCJSValue.cpp: (JSC::JSValue::dumpInContextAssumingStructure const): * Source/JavaScriptCore/wasm/WasmOMGIRGenerator.cpp: (JSC::Wasm::OMGIRGenerator::emitIndirectCall): (JSC::Wasm::OMGIRGenerator::createCallPatchpoint): (JSC::Wasm::prepareForTailCallImpl): (JSC::Wasm::OMGIRGenerator::createTailCallPatchpoint): (JSC::Wasm::OMGIRGenerator::addCall): (JSC::Wasm::OMGIRGenerator::createCallConstrainedArgs): Deleted. * Source/JavaScriptCore/wasm/WasmOMGIRGenerator32_64.cpp: (JSC::Wasm::OMGIRGenerator::addArguments): (JSC::Wasm::OMGIRGenerator::emitIndirectCall): (JSC::Wasm::OMGIRGenerator::createCallPatchpoint): (JSC::Wasm::prepareForTailCallImpl): (JSC::Wasm::OMGIRGenerator::createTailCallPatchpoint): (JSC::Wasm::OMGIRGenerator::addCall): (JSC::Wasm::OMGIRGenerator::createCallConstrainedArgs): Deleted. Canonical link: https://commits.webkit.org/289498@main (cherry picked from commit 82b8457)
https://bugs.webkit.org/show_bug.cgi?id=282870 Reviewed by OOPS. This patch re-lands 287649@main, removing a spurious assert on 64-bit. Implement OMG tail calls. The big difference from 64-bit is that Int64 args (but not double args) need to be split when entering into the patchpoint. We also have no non-callee-save registers to pass into the tail call patchpoint, so we re-purpose some unused slots on the stack. * JSTests/wasm/stress/tail-call-simple-i64.js: Added. (from.string_appeared_here.import.as.assert.from.string_appeared_here.let.wat.module.func.call_same_size.export.string_appeared_here.result.i64.i64.const.600000001337.return_call.callee_same_size.func.callee_same_size.param.i.i64.result.i64.i64.add.local.i.i64.const.42.func.call_same_size_with_stack.export.string_appeared_here.param.i0.i64.param.i1.i64.param.i2.i64.param.i3.i64.param.i4.i64.param.i5.i64.param.i6.i64.param.i7.i64.param.i8.i64.param.i9.i64.result.i64.i64.const.600000001337.i64.const.1.i64.const.2.i64.const.3.i64.const.4.i64.const.5.i64.const.6.i64.const.7.i64.const.8.i64.const.40000000009.return_call.callee_same_size_with_stack.func.callee_same_size_with_stack.param.i0.i64.param.i1.i64.param.i2.i64.param.i3.i64.param.i4.i64.param.i5.i64.param.i6.i64.param.i7.i64.param.i8.i64.param.i9.i64.result.i64.i64.add.local.i9.local.i2.func.call_bigger_with_stack.export.string_appeared_here.result.i64.i64.const.600000001337.i64.const.1.i64.const.2.i64.const.3.i64.const.4.i64.const.5.i64.const.6.i64.const.7.i64.const.8.i64.const.500000000090.return_call.callee_bigger_with_stack.func.callee_bigger_with_stack.param.i0.i64.param.i1.i64.param.i2.i64.param.i3.i64.param.i4.i64.param.i5.i64.param.i6.i64.param.i7.i64.param.i8.i64.param.i9.i64.result.i64.i64.add.local.i9.local.i2.func.call_smaller_with_stack.export.string_appeared_here.param.i0.i64.param.i1.i64.param.i2.i64.param.i3.i64.param.i4.i64.param.i5.i64.param.i6.i64.param.i7.i64.param.i8.i64.param.i9.i64.param.i10.i64.param.i11.i64.result.i64.i64.const.600000001337.i64.const.1.i64.const.2.i64.const.3.i64.const.4.i64.const.5.i64.const.6.i64.const.7.i64.const.8.i64.const.500000000090.return_call.callee_smaller_with_stack.func.callee_smaller_with_stack.param.i0.i64.param.i1.i64.param.i2.i64.param.i3.i64.param.i4.i64.param.i5.i64.param.i6.i64.param.i7.i64.param.i8.i64.param.i9.i64.result.i64.i64.add.local.i9.local.i2.let.badArgs.new.Array.12.fill.0xAAAAn.async test): * Source/JavaScriptCore/assembler/MacroAssemblerARMv7.h: (JSC::MacroAssemblerARMv7::transfer64): * Source/JavaScriptCore/jit/Width.h: * Source/JavaScriptCore/wasm/WasmOMGIRGenerator.cpp: * Source/JavaScriptCore/wasm/WasmOMGIRGenerator32_64.cpp: (JSC::Wasm::OMGIRGenerator::addArguments): (JSC::Wasm::OMGIRGenerator::emitIndirectCall): (JSC::Wasm::OMGIRGenerator::createCallConstrainedArgs): (JSC::Wasm::OMGIRGenerator::createCallPatchpoint): (JSC::Wasm::prepareForTailCallImpl): (JSC::Wasm::OMGIRGenerator::createTailCallPatchpoint): Originally-landed-as: 287649@main (da8e66a). https://bugs.webkit.org/show_bug.cgi?id=282870 Canonical link: https://commits.webkit.org/292059@main (cherry picked from commit ec39ad5)
https://bugs.webkit.org/show_bug.cgi?id=287138 rdar://144289165 Reviewed by Keith Miller. This patch leverages PC to CodeOriginMap in OMG and avoids storing CallSiteIndex for each inlinig function entrance and exit. Wasm can have super very small functions. And when they get inlined, storing CallSiteIndex itself becomes huge bottleneck. In this patch, we implement stack frame traversing mechanism without using CallSiteIndex stored in the stack frame. 1. For the top-most frame, we rely on CallSiteIndex still. So whenever we throw an error from wasm, we set CallSiteIndex to the stack before that. 2. For the stack traversing for the caller functions, we use PC to look up the corresponding CallSiteIndex. We construct PC to CallSiteIndex map in OMG and StackVisitor will query to OMG callee to obtain appropriate CallSiteIndex with PC. 3. (1) does not work for bound-checking exception since we need to throw an error before storing CallSiteIndex. So in the wasm fault signal handler, we store PC to wasm instance. And we store appropriate CallSiteIndex in the function throwing an error actually. We use stored PC to obtain CallSiteIndex. * Source/JavaScriptCore/JavaScriptCore.xcodeproj/project.pbxproj: * Source/JavaScriptCore/Sources.txt: * Source/JavaScriptCore/b3/B3Procedure.h: * Source/JavaScriptCore/b3/air/AirCode.h: * Source/JavaScriptCore/b3/air/AirCustom.cpp: (JSC::B3::Air::WasmBoundsCheckCustom::generate): * Source/JavaScriptCore/b3/testb3_7.cpp: (testWasmBoundsCheck): * Source/JavaScriptCore/b3/testb3_8.cpp: (testStoreAfterClobberExitsSideways): (testStoreAfterClobberExitsSidewaysSuccessor): * Source/JavaScriptCore/interpreter/CallFrame.h: (JSC::CallFrame::rawReturnPC const): (JSC::CallFrame::rawReturnPCForInspection const): Deleted. * Source/JavaScriptCore/interpreter/StackVisitor.cpp: (JSC::StackVisitor::StackVisitor): (JSC::StackVisitor::updatePreviousReturnPCIfNecessary): (JSC::StackVisitor::readNonInlinedFrame): (JSC::StackVisitor::readInlinableNativeCalleeFrame): (JSC::StackVisitor::readInlinedFrame): * Source/JavaScriptCore/interpreter/StackVisitor.h: (JSC::StackVisitor::Frame::returnPC const): * Source/JavaScriptCore/jit/PCToCodeOriginMap.cpp: (JSC::PCToCodeOriginMapBuilder::PCToCodeOriginMapBuilder): * Source/JavaScriptCore/jit/PCToCodeOriginMap.h: * Source/JavaScriptCore/runtime/MachineContext.h: (JSC::MachineContext::stackPointerImpl): (JSC::MachineContext::framePointerImpl): (JSC::MachineContext::instructionPointerImpl): (JSC::MachineContext::argumentPointer<1>): (JSC::MachineContext::wasmInstancePointer): (JSC::MachineContext::llintInstructionPointer): * Source/JavaScriptCore/tools/VMInspector.cpp: (JSC::VMInspector::dumpRegisters): * Source/JavaScriptCore/wasm/WasmBBQPlan.cpp: (JSC::Wasm::BBQPlan::work): * Source/JavaScriptCore/wasm/WasmCallee.cpp: (JSC::Wasm::OptimizingJITCallee::tryGetCallSiteIndex const): (JSC::Wasm::OptimizingJITCallee::materializePCToOriginMap): * Source/JavaScriptCore/wasm/WasmCallee.h: * Source/JavaScriptCore/wasm/WasmCompilationContext.cpp: Removed. * Source/JavaScriptCore/wasm/WasmCompilationContext.h: * Source/JavaScriptCore/wasm/WasmFaultSignalHandler.cpp: (JSC::Wasm::trapHandler): * Source/JavaScriptCore/wasm/WasmOMGIRGenerator.cpp: (JSC::Wasm::OMGIRGenerator::OMGIRGenerator): (JSC::Wasm::OMGIRGenerator::emitExceptionCheck): (JSC::Wasm::OMGIRGenerator::addTableGet): (JSC::Wasm::OMGIRGenerator::addTableSet): (JSC::Wasm::OMGIRGenerator::addRefAsNonNull): (JSC::Wasm::OMGIRGenerator::addTableInit): (JSC::Wasm::OMGIRGenerator::addTableFill): (JSC::Wasm::OMGIRGenerator::addTableCopy): (JSC::Wasm::OMGIRGenerator::addUnreachable): (JSC::Wasm::OMGIRGenerator::addMemoryFill): (JSC::Wasm::OMGIRGenerator::addMemoryInit): (JSC::Wasm::OMGIRGenerator::addMemoryCopy): (JSC::Wasm::OMGIRGenerator::load): (JSC::Wasm::OMGIRGenerator::store): (JSC::Wasm::OMGIRGenerator::fixupPointerPlusOffsetForAtomicOps): (JSC::Wasm::OMGIRGenerator::atomicLoad): (JSC::Wasm::OMGIRGenerator::atomicStore): (JSC::Wasm::OMGIRGenerator::atomicBinaryRMW): (JSC::Wasm::OMGIRGenerator::atomicCompareExchange): (JSC::Wasm::OMGIRGenerator::atomicWait): (JSC::Wasm::OMGIRGenerator::atomicNotify): (JSC::Wasm::OMGIRGenerator::addI31GetS): (JSC::Wasm::OMGIRGenerator::addI31GetU): (JSC::Wasm::OMGIRGenerator::pushArrayNew): (JSC::Wasm::OMGIRGenerator::addArrayGet): (JSC::Wasm::OMGIRGenerator::emitArrayNullCheck): (JSC::Wasm::OMGIRGenerator::addArraySet): (JSC::Wasm::OMGIRGenerator::addArrayLen): (JSC::Wasm::OMGIRGenerator::addArrayFill): (JSC::Wasm::OMGIRGenerator::addArrayCopy): (JSC::Wasm::OMGIRGenerator::addArrayInitElem): (JSC::Wasm::OMGIRGenerator::addArrayInitData): (JSC::Wasm::OMGIRGenerator::addStructNew): (JSC::Wasm::OMGIRGenerator::addStructNewDefault): (JSC::Wasm::OMGIRGenerator::addStructGet): (JSC::Wasm::OMGIRGenerator::addStructSet): (JSC::Wasm::OMGIRGenerator::emitRefTestOrCast): (JSC::Wasm::OMGIRGenerator::addThrow): (JSC::Wasm::OMGIRGenerator::addThrowRef): (JSC::Wasm::OMGIRGenerator::addRethrow): (JSC::Wasm::prepareForTailCallImpl): (JSC::Wasm::OMGIRGenerator::emitInlineDirectCall): (JSC::Wasm::OMGIRGenerator::addCall): (JSC::Wasm::OMGIRGenerator::addCallIndirect): (JSC::Wasm::OMGIRGenerator::addCallRef): (JSC::Wasm::OMGIRGenerator::origin): (JSC::Wasm::parseAndCompileOMG): (JSC::Wasm::OMGIRGenerator::emitChecksForModOrDiv): (JSC::Wasm::OMGIRGenerator::addI32TruncSF64): (JSC::Wasm::OMGIRGenerator::addI32TruncSF32): (JSC::Wasm::OMGIRGenerator::addI32TruncUF64): (JSC::Wasm::OMGIRGenerator::addI32TruncUF32): (JSC::Wasm::OMGIRGenerator::addI64TruncSF64): (JSC::Wasm::OMGIRGenerator::addI64TruncUF64): (JSC::Wasm::OMGIRGenerator::addI64TruncSF32): (JSC::Wasm::OMGIRGenerator::addI64TruncUF32): * Source/JavaScriptCore/wasm/WasmOMGIRGenerator32_64.cpp: (JSC::Wasm::OMGIRGenerator::OMGIRGenerator): (JSC::Wasm::prepareForTailCallImpl): (JSC::Wasm::parseAndCompileOMG): * Source/JavaScriptCore/wasm/WasmOMGPlan.cpp: (JSC::Wasm::OMGPlan::work): * Source/JavaScriptCore/wasm/WasmOSREntryPlan.cpp: (JSC::Wasm::OSREntryPlan::work): * Source/JavaScriptCore/wasm/WasmOpcodeOrigin.h: * Source/JavaScriptCore/wasm/WasmOperations.cpp: (JSC::Wasm::JSC_DEFINE_NOEXCEPT_JIT_OPERATION): * Source/JavaScriptCore/wasm/WasmSlowPaths.cpp: (JSC::LLInt::slow_path_wasm_throw_exception): * Source/JavaScriptCore/wasm/js/JSWebAssemblyInstance.h: * Source/WTF/wtf/PlatformHave.h: Canonical link: https://commits.webkit.org/289952@main (cherry picked from commit 005a3be)
https://bugs.webkit.org/show_bug.cgi?id=292428 Reviewed by Justin Michaud. Incorporates relevant changes from WasmOMGIRGenerator.cpp, that set the opcode origin correctly on 32bit CPUs. This fixes the following failures on 32bit when OMG is enabled: - JSTests/wasm/stress/simple-inline-stacktrace.js - JSTests/wasm/stress/simple-inline-stacktrace-with-catch.js - JSTests/wasm/function-tests/stack-trace.js * Source/JavaScriptCore/wasm/WasmOMGIRGenerator32_64.cpp: (JSC::Wasm::OMGIRGenerator::OMGIRGenerator): adds a new first argument CompilationContext& m_context (JSC::Wasm::OMGIRGenerator::emitInlineDirectCall): adds argument m_context to the call to makeUnique<OMGIRGenerator> (JSC::Wasm::OMGIRGenerator::origin): incorporates the same changes in this function from WasmOMGIRGenerator.cpp (JSC::Wasm::parseAndCompileOMG): adds new context argument to the OMGIRGenerator constructor Canonical link: https://commits.webkit.org/294475@main (cherry picked from commit 050ce79)
…types in hot functions. https://bugs.webkit.org/show_bug.cgi?id=293113 rdar://151464447 Reviewed by Daniel Liu and Keith Miller. 274558@main changed rtt field of WasmToWasmImportableFunction from CompactPtr to normal pointer, but it didn't change OMG code generator's loadCompactPtr. So we are materializing a pointer incorrectly. This patch removes loadCompactPtr and use normal Load for OMG. * JSTests/wasm/stress/resources/wasm-gc-ref-cast.wasm: Added. * JSTests/wasm/stress/resources/wasm-gc-ref-cast.wat: Added. * JSTests/wasm/stress/wasm-gc-ref-cast.mjs: Added. * Source/JavaScriptCore/wasm/WasmFormat.h: * Source/JavaScriptCore/wasm/WasmOMGIRGenerator.cpp: (JSC::Wasm::OMGIRGenerator::emitLoadRTTFromFuncref): * Source/JavaScriptCore/wasm/WasmOMGIRGenerator32_64.cpp: (JSC::Wasm::OMGIRGenerator::emitLoadRTTFromFuncref): Canonical link: https://commits.webkit.org/295902@main (cherry picked from commit f63d690)
https://bugs.webkit.org/show_bug.cgi?id=298604 Reviewed by Justin Michaud. Bring in the missing bits from https://commits.webkit.org/289952@main. Canonical link: https://commits.webkit.org/299756@main (cherry picked from commit 45e6922943c71b908f8c6fde447ef5810b0cd1fe)
…ocks come from https://bugs.webkit.org/show_bug.cgi?id=298536 Reviewed by Yusuke Suzuki. Bring in https://commits.webkit.org/297341@main. Canonical link: https://commits.webkit.org/300220@main (cherry picked from commit b627e177be18f30eda11738c43f6fa97ccfebdcb)
…n state Function-level transplant of prepareForTailCallImpl from upstream 9f179c4476dd (the last change before OMG-ARMv7 was removed upstream), replacing our re-land-era copy. This incorporates, in one verifiable step: - 11eaa3910d44 ([JSC] Fix spilling macro scratch reg in OMG tail calls) - 9f179c4476dd (Size in bytes to clobber is not aligned on 32 bit OMGIRGenerator's prepareForTailCallImpl, bug 302776) - the prepareForTailCallImpl portions of d934b72 (bug 294413), notably restoring srcOffset from the tmp spill when clobbered. The enclosing patchpoint/caller block is byte-identical between our tree and upstream at that commit, so the function body is the entire delta. Adapted rawReturnPC() to this tree's rawReturnPCForInspection(). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Hand-applied 32-bit adaptation of ed72fde (Correctly load RTT in WasmOMGIRGenerator32_64.cpp, bug 291513), required for coherence after taking f63d690: emitLoadRTTFromFuncref now returns pointerType(), so emitLoadRTTFromObject must too (its RefPtr field is one pointer wide; the old code loaded 8 bytes as Types::Ref and truncated), and the shared use sites must stop wrapping rtt in truncate(), which is malformed B3 on an Int32 input. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…eption checks Finish what 287138@main (Do not use stored call-site-index for OMG) did for the shared generator: emitExceptionCheck now takes the B3::Origin, stores the OMGOrigin's CallSiteIndex at trap sites (this tree's bit_cast-of-Origin::data idiom, matching WasmOMGIRGenerator.cpp), and every generator lambda captures origin = this->origin() at emission time. Also add the missing DisallowMacroScratchRegisterUsage.h include needed by the synced prepareForTailCallImpl and adopt the returnPCForInspection() spelling. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Follow-up to the previous commit's mechanical transform, which only injected the origin init-capture into setGenerator([...]) lambdas: - restoreWasmContextInstance / memory-cage patchpoints: revert the spurious (and malformed, [,...]) capture injection; those bodies do not use origin. - setWasmBoundsCheckGenerator: name the WasmBoundsCheckValue parameter and use originValue->origin(), matching WasmOMGIRGenerator.cpp. - castFailure plain lambda: capture origin = this->origin(). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…-unified builds 287138@main's signal handler recovers the instance with jsSecureCast<JSWebAssemblyInstance*>, which needs the inline JSCell::type(). Upstream relies on unified builds to supply it; under --no-unified-builds the definition is absent and the executable link fails with an undefined reference to JSC::JSCell::type(). Include the inlines header the way sibling wasm translation units do. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Here are some minor workarounds for some crashes and hangs on 32-bit. I have also included a js3 cli wrapper with a subset of the tests that should work fine on 32-bit. This still needs to be reviewed, but should help with testing in the meantime.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
16 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
I have a batch of backports or dowstream patches on 238 that seem like they might be useful. I will make a build and test it locally on my rpi3 before merging.
Relevant: #1695
3cfae84