ExecutableAllocator: Do not store things in g_config when USE(SYSTEM_… #7
Conversation
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
…MALLOC). Following 41bdcb7, two additional slots were added to g_config in order to store these pointers for use in bmalloc and Gigacage. However, when USE(SYSTEM_MALLOC) is enabled, there are no slots reserved for Gigacage, and so this collided with g_wtfConfig and overwrote data there instead. This should fix crashes seen on Haiku, which enables USE(SYSTEM_MALLOC).
pulkomandy
pushed a commit
that referenced
this pull request
Jun 12, 2022
…arget labels. https://bugs.webkit.org/show_bug.cgi?id=240370 Reviewed by Saam Barati. Disassemblies used to look like this: 0x10e480ff8: ldurb w17, [x0, #7] 0x10e480ffc: cmp w17, #0 0x10e481000: b.hi 0x10e48103c 0x10e481004: stur x0, [fp, #-72] ... 0x10e481040: movk x3, #0xfffe, lsl #48 0x10e481044: b 0x10e4814f4 0x10e481048: nop With this patch, it will now look like this: <748> 0x10e120aec: ldurb w17, [x0, #7] <752> 0x10e120af0: cmp w17, #0 <756> 0x10e120af4: b.hi 0x10e120b30 -> <816> <760> 0x10e120af8: stur x0, [fp, #-80] ... <820> 0x10e120b34: movk x3, #0xfffe, lsl #48 <824> 0x10e120b38: b 0x10e120fc8 -> <1992> <828> 0x10e120b3c: nop 1. Each instruction pc is now prefixed with a pc index i.e. the offset of the pc address from the start of the compilation unit e.g. <756>. 2. Relative branches now show the branch target as a pc index (effectively, an internal label in this compilation unit) in addition to the pc address e.g. the "-> <816>" in: <756> 0x10e120af4: b.hi 0x10e120b30 -> <816> Also fixed a formatting bug where the space between relative branch instructions and their target pc was short 2 spaces. 3. If the relative branch target is a known thunk, the disassembler will now print the thunk label e.g. <828> 0x10e12033c: bl 0x10e0f0a00 -> <thunk: get_from_scope thunk> <1476> 0x10e120dc4: cbnz x16, 0x10e104100 -> <thunk: handleExceptionWithCallFrameRollback> <2368> 0x10e121140: b 0x10e10c000 -> <thunk: DFG OSR exit generation thunk> Introduced a FINALIZE_THUNK macro that will be used instead of FINALIZE_CODE in thunk generators. By doing so, thunk labels will automatically be registered with the disassembler, and will be used for the above look up. Thunk label registration is only done if disassembly is enabled. 4. If the branch target is neither an internal label nor a thunk, then the disassembler will print some useful info about it to the best of its knowledge e.g. <168> 0x10e1002e8: b 0x10e120b60 -> <JIT PC> <168> 0x10e1002e8: b 0x10e120b60 -> <LLInt PC> <168> 0x10e1002e8: b 0x10e120b60 -> <unknown> 5. The disassemble() function now takes 2 additional arguments: codeStart, and codeEnd. These are needed so that the disassembler can compute the pc index for each instruction, as well as determine if a branch target is internal to this compilation unit, or pointing out of it. This feature is currently only supported for the ARM64 disassembler. Printing of JIT operation labels (via movz + movk + indirect branch) is not yet supported. * assembler/LinkBuffer.cpp: (JSC::LinkBuffer::finalizeCodeWithDisassemblyImpl): * assembler/LinkBuffer.h: (JSC::LinkBuffer::setIsThunk): * b3/air/AirDisassembler.cpp: (JSC::B3::Air::Disassembler::dump): * dfg/DFGDisassembler.cpp: (JSC::DFG::Disassembler::dumpDisassembly): * dfg/DFGThunks.cpp: (JSC::DFG::osrExitGenerationThunkGenerator): (JSC::DFG::osrEntryThunkGenerator): * disassembler/ARM64/A64DOpcode.cpp: (JSC::ARM64Disassembler::A64DOpcode::appendPCRelativeOffset): (JSC::ARM64Disassembler::A64DOpcodeConditionalBranchImmediate::format): * disassembler/ARM64/A64DOpcode.h: (JSC::ARM64Disassembler::A64DOpcode::A64DOpcode): (JSC::ARM64Disassembler::A64DOpcode::appendPCRelativeOffset): Deleted. * disassembler/ARM64Disassembler.cpp: (JSC::tryToDisassemble): * disassembler/CapstoneDisassembler.cpp: (JSC::tryToDisassemble): * disassembler/Disassembler.cpp: (JSC::disassemble): (JSC::disassembleAsynchronously): (JSC::ensureThunkLabelMap): (JSC::registerThunkLabel): (JSC::labelForThunk): * disassembler/Disassembler.h: (JSC::tryToDisassemble): * disassembler/RISCV64Disassembler.cpp: (JSC::tryToDisassemble): * disassembler/X86Disassembler.cpp: (JSC::tryToDisassemble): * ftl/FTLThunks.cpp: (JSC::FTL::genericGenerationThunkGenerator): (JSC::FTL::slowPathCallThunkGenerator): * jit/JIT.cpp: (JSC::JIT::consistencyCheckGenerator): * jit/JITCall.cpp: (JSC::JIT::returnFromBaselineGenerator): * jit/JITDisassembler.cpp: (JSC::JITDisassembler::dump): (JSC::JITDisassembler::dumpDisassembly): * jit/JITDisassembler.h: * jit/JITOpcodes.cpp: (JSC::JIT::valueIsFalseyGenerator): (JSC::JIT::valueIsTruthyGenerator): (JSC::JIT::op_throw_handlerGenerator): (JSC::JIT::op_enter_handlerGenerator): (JSC::JIT::op_check_traps_handlerGenerator): * jit/JITPropertyAccess.cpp: (JSC::JIT::slow_op_get_by_val_callSlowOperationThenCheckExceptionGenerator): (JSC::JIT::slow_op_get_private_name_callSlowOperationThenCheckExceptionGenerator): (JSC::JIT::slow_op_put_by_val_callSlowOperationThenCheckExceptionGenerator): (JSC::JIT::slow_op_put_private_name_callSlowOperationThenCheckExceptionGenerator): (JSC::JIT::slow_op_del_by_id_callSlowOperationThenCheckExceptionGenerator): (JSC::JIT::slow_op_del_by_val_callSlowOperationThenCheckExceptionGenerator): (JSC::JIT::slow_op_get_by_id_callSlowOperationThenCheckExceptionGenerator): (JSC::JIT::slow_op_get_by_id_with_this_callSlowOperationThenCheckExceptionGenerator): (JSC::JIT::slow_op_put_by_id_callSlowOperationThenCheckExceptionGenerator): (JSC::JIT::generateOpResolveScopeThunk): (JSC::JIT::slow_op_resolve_scopeGenerator): (JSC::JIT::generateOpGetFromScopeThunk): (JSC::JIT::slow_op_get_from_scopeGenerator): (JSC::JIT::slow_op_put_to_scopeGenerator): * jit/SlowPathCall.cpp: (JSC::JITSlowPathCall::generateThunk): * jit/SpecializedThunkJIT.h: (JSC::SpecializedThunkJIT::finalize): * jit/ThunkGenerator.h: * jit/ThunkGenerators.cpp: (JSC::handleExceptionGenerator): (JSC::handleExceptionWithCallFrameRollbackGenerator): (JSC::popThunkStackPreservesAndHandleExceptionGenerator): (JSC::checkExceptionGenerator): (JSC::throwExceptionFromCallSlowPathGenerator): (JSC::linkCallThunkGenerator): (JSC::linkPolymorphicCallThunkGenerator): (JSC::virtualThunkFor): (JSC::nativeForGenerator): (JSC::arityFixupGenerator): (JSC::unreachableGenerator): (JSC::stringGetByValGenerator): (JSC::boundFunctionCallGenerator): (JSC::remoteFunctionCallGenerator): * llint/LLIntThunks.cpp: (JSC::LLInt::generateThunkWithJumpTo): (JSC::LLInt::generateThunkWithJumpToPrologue): (JSC::LLInt::generateThunkWithJumpToLLIntReturnPoint): (JSC::LLInt::createJSGateThunk): (JSC::LLInt::createWasmGateThunk): (JSC::LLInt::createTailCallGate): (JSC::LLInt::tagGateThunk): (JSC::LLInt::untagGateThunk): * yarr/YarrDisassembler.cpp: (JSC::Yarr::YarrDisassembler::dump): (JSC::Yarr::YarrDisassembler::dumpDisassembly): * yarr/YarrDisassembler.h: Canonical link: https://commits.webkit.org/250547@main git-svn-id: https://svn.webkit.org/repository/webkit/trunk@294180 268f45cc-cd09-0410-ab3c-d52691b4dbfc
pulkomandy
pushed a commit
that referenced
this pull request
Nov 22, 2022
…a rejected promise https://bugs.webkit.org/show_bug.cgi?id=247785 rdar://102325201 Reviewed by Yusuke Suzuki. Rest parameter should be caught in async function. So, running this JavaScript program should print "caught". ``` async function f(...[[]]) { } f().catch(e => print("caught")); ``` V8 (used console.log) ``` $ node input.js caught ``` GraalJS ``` $ js input.js caught ``` https://tc39.es/ecma262/#sec-async-function-definitions ... AsyncFunctionDeclaration[Yield, Await, Default] : async [no LineTerminator here] function BindingIdentifier[?Yield, ?Await] ( FormalParameters[~Yield, +Await] ) { AsyncFunctionBody } [+Default] async [no LineTerminator here] function ( FormalParameters[~Yield, +Await] ) { AsyncFunctionBody } AsyncFunctionExpression : async [no LineTerminator here] function BindingIdentifier[~Yield, +Await]opt ( FormalParameters[~Yield, +Await] ) { AsyncFunctionBody } ... According to the spec, it indicates `FormalParameters` is used for Async Function, where `FormalParameters` can be converted to `FunctionRestParameter`. https://tc39.es/ecma262/#sec-parameter-lists ... FormalParameters[Yield, Await] : [empty] FunctionRestParameter[?Yield, ?Await] FormalParameterList[?Yield, ?Await] FormalParameterList[?Yield, ?Await] , FormalParameterList[?Yield, ?Await] , FunctionRestParameter[?Yield, ?Await] ... And based on RS: EvaluateAsyncFunctionBody, it will invoke the promise.reject callback function with abrupt value ([[value]] of non-normal completion record). https://tc39.es/ecma262/#sec-runtime-semantics-evaluateasyncfunctionbody ... 2. Let declResult be Completion(FunctionDeclarationInstantiation(functionObject, argumentsList)). 3. If declResult is an abrupt completion, then a. Perform ! Call(promiseCapability.[[Reject]], undefined, « declResult.[[Value]] »). ... In that case, any non-normal results of evaluating rest parameters should be caught and passed to the reject callback function. To resolve this problem, we should allow the emitted RestParameterNode be wrapped by the catch handler for promise. However, we should remove `m_restParameter` and emit rest parameter byte code in `initializeDefaultParameterValuesAndSetupFunctionScopeStack` if we can prove that change has no side effect. In that case, we can only use one exception handler. Current fix is to add another exception handler. And move the handler byte codes to the bottom of code block in order to make other byte codes as much compact as possible. Input: ``` async function f(arg0, ...[[]]) { } f(); ``` Dumped Byte Codes: ``` ... bb#2 Predecessors: [ #1 ] [ 20] mov dst:loc9, src:<JSValue()>(const0) ... bb#3 Predecessors: [ #2 ] [ 29] get_rest_length dst:loc11, numParametersToSkip:1 ... bb#12 Predecessors: [ #8 #9 #10 ] [ 138] new_func_exp dst:loc10, scope:loc4, functionDecl:0 ... bb#13 Predecessors: [ ] [ 170] catch exception:loc10, thrownValue:loc8 [ 174] jmp targetLabel:8(->182) Successors: [ #15 ] bb#14 Predecessors: [ #7 #11 ] [ 176] catch exception:loc10, thrownValue:loc8 [ 180] jmp targetLabel:2(->182) Successors: [ #15 ] bb#15 Predecessors: [ #13 #14 ] [ 182] mov dst:loc12, src:Undefined(const1) ... Exception Handlers: 1: { start: [ 20] end: [ 29] target: [ 170] } synthesized catch 2: { start: [ 29] end: [ 138] target: [ 176] } synthesized catch ``` * JSTests/stress/catch-rest-parameter.js: Added. (throwError): (shouldThrow): (async f): (throwError.async f): (throwError.async let): (async let): (x.async f): (x): (async shouldThrow): * Source/JavaScriptCore/bytecompiler/BytecodeGenerator.cpp: (JSC::BytecodeGenerator::BytecodeGenerator): (JSC::BytecodeGenerator::initializeDefaultParameterValuesAndSetupFunctionScopeStack): * Source/JavaScriptCore/bytecompiler/BytecodeGenerator.h: Canonical link: https://commits.webkit.org/256864@main
pulkomandy
pushed a commit
that referenced
this pull request
Mar 5, 2023
https://bugs.webkit.org/show_bug.cgi?id=251063 rdar://104585575 Reviewed by Mark Lam and Justin Michaud. This patch enhances CallFrame::dump to support wasm frames in btjs stacktrace. The example is as follows. frame #0: 0x00000001035fca78 JavaScriptCore`JSC::functionBreakpoint(globalObject=0x000000012f410068, callFrame=0x000000016fdfa9d0) at JSDollarVM.cpp:2273:9 [opt] frame #1: 0x000000010ec44204 0x10eccc5dc frame #2: 0x000000010eccc5dc callback#Dwaxn6 [Baseline bc#50](Undefined) frame #3: 0x000000010ec4ca84 wasm-stub [WasmToJS](Wasm::Instance: 0x10d29da40) frame #4: 0x000000010ed0c060 <?>.wasm-function[1] [OMG](Wasm::Instance: 0x10d29da40) frame #5: 0x000000010ed100d0 jsToWasm#CWTx6k [FTL bc#22](Cell[JSModuleEnvironment]: 0x12f524540, Cell[WebAssemblyFunction]: 0x10d06a3a8, 1, 2, 3) frame #6: 0x000000010ec881b0 #D5ymZE [Baseline bc#733](Undefined, Cell[Generator]: 0x12f55c180, 1, Cell[Object]: 0x12f69dfc0, 0, Cell[JSLexicalEnvironment]: 0x12f52cee0) frame #7: 0x000000010ec3c008 asyncFunctionResume#A4ayYg [LLInt bc#49](Undefined, Cell[Generator]: 0x12f55c180, Cell[Object]: 0x12f69dfc0, 0) frame #8: 0x000000010ec3c008 promiseReactionJobWithoutPromise#D0yDF1 [LLInt bc#25](Undefined, Cell[Function]: 0x12f44f3c0, Cell[Object]: 0x12f69dfc0, Cell[Generator]: 0x12f55c180) frame #9: 0x000000010ec80ec0 promiseReactionJob#EdShZz [Baseline bc#74](Undefined, Undefined, Cell[Function]: 0x12f44f3c0, Cell[Object]: 0x12f69dfc0, Cell[Generator]: 0x12f55c180) frame #10: 0x000000010ec3c728 frame #11: 0x0000000103137560 JavaScriptCore`JSC::Interpreter::executeCall(JSC::JSGlobalObject*, JSC::JSObject*, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) [inlined] JSC::JITCode::execute(this=<unavailable>, vm=<unavailable>, protoCallFrame=<unavailable>) at JITCodeInlines.h:42:38 [opt] frame #12: 0x0000000103137524 JavaScriptCore`JSC::Interpreter::executeCall(this=<unavailable>, lexicalGlobalObject=<unavailable>, function=<unavailable>, callData=<unavailable>, thisValue=<unavailable>, args=<unavailable>) at Interpreter.cpp:1093:27 [opt] frame #13: 0x000000010349d6d0 JavaScriptCore`JSC::runJSMicrotask(globalObject=0x000000012f410068, identifier=(m_identifier = 81), job=JSValue @ x22, argument0=JSValue @ x26, argument1=JSValue @ x25, argument2=<unavailable>, argument3=<unavailable>) at JSMicrotask.cpp:98:9 [opt] frame #14: 0x00000001039dfc54 JavaScriptCore`JSC::VM::drainMicrotasks() (.cold.1) at VM.cpp:0:9 [opt] frame #15: 0x00000001035e58a4 JavaScriptCore`JSC::VM::drainMicrotasks() [inlined] JSC::MicrotaskQueue::dequeue(this=<unavailable>) at VM.cpp:0:9 [opt] frame #16: 0x00000001035e5894 JavaScriptCore`JSC::VM::drainMicrotasks(this=0x000000012f000000) at VM.cpp:1255:46 [opt] ... * Source/JavaScriptCore/interpreter/CallFrame.cpp: (JSC::CallFrame::dump const): Canonical link: https://commits.webkit.org/259262@main
pulkomandy
pushed a commit
that referenced
this pull request
Sep 2, 2025
…ate-event/intercept-detach-multiple.html is crashing https://bugs.webkit.org/show_bug.cgi?id=297414 rdar://158349001 Reviewed by Ben Nham. The Navigation API spec in Step #7 here: (https://html.spec.whatwg.org/multipage/browsing-the-web.html#getting-session-history-entries-for-the-navigation-api) says that when getting the entries, we should start at index (startingIndex - 1) and work backwards while prepending the entries to our list. The code wasn't doing that. It was starting at 0 and working up to (startingIndex - 1). Given that we break if we see an entry with a different domain, that means that in the scenario where the entries before (startingIndex - 1) are: 1. foo.com 2. foo.com#A 3. bar.com 4. foo.com#B 5. current entry (of foo.com origin) And the origin we're filtering by is foo.com, the entries we'll end up with are: 1. foo.com 2. foo.com#A Whereas we should have ended up with: 1. foo.com#B m_entries corresponds to the entries that this navigation object can navigate the frame to. It cannot go from entry 5 to 2 because that would have gone to 3 first and cross-origin navigation aren't allowed by this API. So 2 should not be in the list at all. That's what is happening in this test. The entries in the list are incorrect and leading to an error down the line. * LayoutTests/TestExpectations: * Source/WebCore/page/Navigation.cpp: (WebCore::Navigation::initializeForNewWindow): Canonical link: https://commits.webkit.org/299078@main
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
…MALLOC).
Following 41bdcb7, two additional slots were added
to g_config in order to store these pointers for use in bmalloc and Gigacage. However, when
USE(SYSTEM_MALLOC) is enabled, there are no slots reserved for Gigacage, and so this collided
with g_wtfConfig and overwrote data there instead.
This should fix crashes seen on Haiku, which enables USE(SYSTEM_MALLOC).