Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: a57cde3b593370e8543005175c58a67609c0caba
https://github.com/WebKit/WebKit/commit/a57cde3b593370e8543005175c58a67609c0caba
Author: Yijia Huang <[email protected]>
Date: 2026-09-15 (Tue, 15 Sep 2026)
Changed paths:
M JSTests/wasm/debugger/tests/tests.py
M Source/JavaScriptCore/wasm/WasmIPIntGenerator.cpp
M Source/JavaScriptCore/wasm/WasmModuleInformation.cpp
M Source/JavaScriptCore/wasm/WasmModuleInformation.h
M Source/JavaScriptCore/wasm/debugger/WasmExecutionHandler.cpp
M Source/JavaScriptCore/wasm/debugger/WasmModuleDebugInfo.h
Log Message:
-----------
[JSC] Reject a WASM breakpoint that isn't at an instruction boundary
https://bugs.webkit.org/show_bug.cgi?id=324283
rdar://187510287
Reviewed by Yusuke Suzuki.
A breakpoint patches byte 0 of an instruction, so Z0 at any other offset
rewrites
an operand instead: i32.const 42 becomes i32.const 0, and since the interpreter
consumes that byte as data rather than dispatching on it, the breakpoint
silently
does not exist. toPhysicalPC only checked that the offset falls inside a
function, so the stub replied OK.
FunctionDebugInfo now records the start offset of every opcode the parser
reports,
and ModuleInformation::isInstructionStart rejects anything else, so
setBreakpoint
replies InvalidAddress. It upper-bounds functions for the containing entry,
which
the Code section fills in index order from a monotonically advancing offset and
so
is sorted by start; an ASSERT_ENABLED check states that. Nested block runs are
the
one shape not reported per opcode -- parseNestedBlocksEagerly consumes a whole
run
in a single step -- but coalesceControlFlow makes the leader's deltaPC jump the
run, so the followers are PCs the interpreter can never occupy.
offsetToNextInstructions cannot answer any of this: it holds edges, so an
instruction with no successor is never a key, and RECORD_NEXT_INSTRUCTION
additionally skips control flow.
The recording sits above didParseOpcode's reachability check because parsing
`unreachable` sets unreachableBlocks before the hook runs, and inside
ENABLE(WEBASSEMBLY_DEBUGGER) because FunctionDebugInfo is declared only there.
The neighbouring RECORD_NEXT_INSTRUCTION block takes the same guard so its gate
and opcode lookup do not compile on ports without the debugger. The debugger
checks in this file drop their Options::enableWasmDebugger() test, which a
non-null m_debugInfo already implies.
Tests:
JSTests/wasm/debugger/tests/tests.py: BreakpointNonInstructionBoundaryTestCase
Canonical link: https://commits.webkit.org/321228@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
