Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 9f9aae3434d37674484277936178e57a9086eae0
https://github.com/WebKit/WebKit/commit/9f9aae3434d37674484277936178e57a9086eae0
Author: Yijia Huang <[email protected]>
Date: 2026-09-18 (Fri, 18 Sep 2026)
Changed paths:
M Source/JavaScriptCore/wasm/debugger/WasmBreakpointManager.cpp
M Source/JavaScriptCore/wasm/debugger/WasmBreakpointManager.h
M Source/JavaScriptCore/wasm/debugger/WasmDebugServerUtilities.h
M Source/JavaScriptCore/wasm/debugger/WasmExecutionHandler.cpp
M Source/JavaScriptCore/wasm/debugger/WasmExecutionHandler.h
M Source/JavaScriptCore/wasm/debugger/tests/ExecutionHandlerTest.cpp
Log Message:
-----------
[JSC] WASM debugger: report an interrupt at a wasm prologue as a real stop
https://bugs.webkit.org/show_bug.cgi?id=324453
rdar://187695269
Reviewed by Mark Lam.
A prologue stop has no pc -- isStoppedAtPrologue() is stopData without one --
yet the
reply advertises the function's first instruction, which has not run. LLDB is
told the
process sits somewhere it has not reached, so a breakpoint later set there is
lifted by
the step-over dance exactly when the program arrives.
An interrupt taken at a prologue now arms that instruction and resumes the
debuggee
alone instead of reporting. Execution reaches the armed byte a few steps later,
so the
stop LLDB receives has a real pc and reason:interrupt, and the server thread
stays
blocked meanwhile and replies when it lands, leaving the packet sequence
unchanged.
setStepBreakpoint becomes setOneTimeBreakpoint<reason>, a template parameter so
its
domain is a static_assert.
Only the interrupt forwards. A prologue StackOverflow reports where it is,
since the
instruction it would forward to never executes, and stopCode's WasmProgramStop
arm
accepts InterruptRequested so that trap still reports rather than hanging.
Canonical link: https://commits.webkit.org/321395@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
