Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: a44ee729d333771aa6990ee138314868be363d82
https://github.com/WebKit/WebKit/commit/a44ee729d333771aa6990ee138314868be363d82
Author: Simon Lewis <[email protected]>
Date: 2026-04-27 (Mon, 27 Apr 2026)
Changed paths:
A Tools/Scripts/generate-cmake-vscode-project-macos
A Tools/lldb/webkit_auto_attach.py
Log Message:
-----------
[CMake] Add generate-cmake-vscode-project-macos for the cmake-mac build
https://bugs.webkit.org/show_bug.cgi?id=313310
Reviewed by David Kilzer.
Sibling of generate-cmake-xcode-project: wraps a configured CMake/Ninja
build directory in a self-contained VS Code multi-root workspace so that
`code WebKitBuild/cmake-mac/ASan/WebKit.code-workspace` lands in a
ready-to-debug session with nothing written into the checkout's .vscode/.
The generated workspace embeds:
- A default ninja build task (Cmd-Shift-B) with $gcc/$swiftc problem
matchers so compile errors land in the Problems panel.
- One CodeLLDB launch config per discovered .app bundle and Mach-O
executable, each with preLaunchTask=ninja, sanitizer environment
(ASAN_OPTIONS / TSAN_OPTIONS plus __XPC_ forwarding), a sourceMap that
inverts the build's -fdebug-prefix-map so editor breakpoints resolve,
and the shared lldbinit. F5 on MiniBrowser builds, launches, and
debugs.
- clangd settings: --compile-commands-dir pointed at the build
directory's compile_commands.json, with the Microsoft C/C++
IntelliSense engine disabled so the two don't fight over hover /
go-to-definition. DerivedSources/<framework> directories are added as
workspace folders so generated message receivers and bindings are
navigable alongside checked-in code.
- Extension recommendations for vadimcn.vscode-lldb and
llvm-vs-code-extensions.vscode-clangd; the script also prints the
`code --install-extension` lines for one-shot setup.
Executable discovery, prefix-map inversion, sanitizer-option derivation
and lldbinit generation are imported from generate-cmake-xcode-project so
the two front ends stay in lock-step as the build evolves.
webkit_auto_attach.py provides the multi-process debugging piece. Loaded
via postRunCommands on the UI-process launch, it derives the build
directory by walking up from the target executable to CMakeCache.txt,
then runs a daemon thread that polls proc_listpids/proc_pidpath (via
ctypes, ~50 ms interval) for processes whose executable lives under
<build-dir>/WebKit.framework/Versions/A/XPCServices/. For each new PID it
fires CodeLLDB's DAP startDebugging reverse-request, so every WebContent,
Networking and GPU process -- including per-tab WebContent instances and
respawns after a crash -- appears as a nested child session in the Call
Stack panel without any manual attach step. Filtering by executable path
under the build directory (rather than process name) scopes attachment to
this exact build; other WebKit-based applications on the machine are left
alone. The poller stops when the UI process exits and degrades to a no-op
when the script is imported under a plain lldb without CodeLLDB.
The attach is a poll, not a suspended-spawn, so the very first
instructions of XPC service entry are not guaranteed to be caught; for
breakpoints anywhere past process bootstrap the experience matches
debugging the same processes from the Xcode wrapper.
Usage:
cmake --preset mac-asan
ninja -C WebKitBuild/cmake-mac/ASan
Tools/Scripts/generate-cmake-vscode-project-macos WebKitBuild/cmake-mac/ASan
code --install-extension vadimcn.vscode-lldb
code --install-extension llvm-vs-code-extensions.vscode-clangd
open WebKitBuild/cmake-mac/ASan/WebKit.code-workspace
# Select MiniBrowser, F5
* Tools/Scripts/generate-cmake-vscode-project-macos: Added.
* Tools/lldb/webkit_auto_attach.py: Added.
Canonical link: https://commits.webkit.org/312150@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
