Breaking the LLDB/Python Revlock
Python has been LLDB’s main scripting language since its inception, powering data formatters, breakpoint callbacks, and a two-way bridge that lets you script LLDB from Python or drive LLDB from an existing interpreter. That power came with a hard constraint: an LLDB binary was locked to the exact Python version it was built against. The coupling was more than an inconvenience. A mismatched libpython crashed the dynamic loader before LLDB could report anything, and importing lldb into an existing interpreter risked a dangerous second copy of Python. This talk covers how we broke that lock so a single LLDB binary now works against any Python from 3.8 up. First, we moved the Python-dependent interpreter into a dynamically loaded plugin whose Python symbols are resolved at runtime by a cross-platform loader that finds a suitable Python, binds to one already mapped, or reports an error instead of crashing. Second, we built against the Stable Python C API, whose abi3 ABI, now usable from SWIG, sets a single floor at 3.8 and produces one version-agnostic extension instead of a per-version binary.
The state of WebAssembly debugging in LLDB
WebAssembly has been a first-class LLVM target for years, and Swift made it official in Swift 6.2, but debugging that code with LLDB is very recent and has taken a substantial, sustained engineering effort. Earlier this year at the LLVM Dev Room at FOSDEM, I argued for extending the GDB Remote Serial Protocol to debug native languages compiled to Wasm and presented the LLDB work needed to make it real. This talk covers what comes next: moving that capability from working to reliable, toward first-class debugging support. The GDB remote approach championed by LLDB is now converging into an industry standard. Alongside existing support in WAMR and V8, WebKit has adopted it, and Wasmtime’s accepted debugging RFC reverses an earlier plan to endorse this exact approach. To ensure correctness, we set out to get the LLDB test suite passing against Wasm, compiling our test programs and running them under a Wasm runtime. That surfaced a long tail of concrete bugs we have been fixing for the 23.x release, and once the suite is green it will run in CI to keep support from regressing.
WebAssembly Debugging with LLDB
WebAssembly support in Swift started as a community project and became an official part of Swift 6.2. As Swift on WebAssembly matures, developers need robust debugging tools to match. This talk presents our work adding native debugging support for Swift targeting Wasm in LLDB. WebAssembly has some unique characteristics, such as its segmented memory address space, and we’ll explore how we made that work with LLDB’s architecture. Additionally, we’ll cover how extensions to the GDB remote protocol enable debugging across various Wasm runtimes, including the WebAssembly Micro Runtime (WAMR), JavaScriptCore (JSC), and WasmKit.
LLDB MCP
This talk introduces the new support for the Model Context Protocol (MCP) in LLDB, enabling agent-driven debugging workflows. MCP provides a standardized way for AI models to access external tools, bridging the gap between large language models and LLDB. Users can interact with the debugger using natural language, which the model translates into LLDB commands executed over MCP. Key benefits include reduced context switching between debugging tools and AI assistants, more intuitive debugging for novice developers, and the ability to leverage AI’s pattern recognition capabilities for tedious or repetitive debugging tasks.
LLDB DAP
lldb-dapis a utility that allows LLDB to work with editors and IDEs that support the Debug Adapter Protocol (DAP), such as Visual Studio Code. It builds on LLDB’s stable API and uses a standardized protocol to act as a bridge between LLDB and other developer tools. It is part of the Xcode developer tools and the open source Swift toolchain. It is also the name of the official VS Code extension, which is available in the Marketplace. We’ll talk about the Debugger Adapter Protocol, how we support it in LLDB and where the line is between the IDE-agnostic tool and the VSCode extension.
LLDB Statusline
Motivated by a better place to show progress events and a way to display the current state of the debugger, I extended command-line LLDB with a statusline. This dedicated area at the bottom of the screen shows things like the current target, the stop reason, and progress updates. The statusline can be customized using LLDB’s format strings. I’ll talk a little bit about the motivation, the implementation, and how to configure it.
MD5 Checksums in LLDB
Support for DWARF MD5 checksums in LLDB.