LLDB in 2025

This post summarizes the major areas of development in LLDB in 2025. I was inspired by Nikita Popov’s “This year in LLVM” and thought it would be interesting to do something similar for LLDB.

My goal was to cover the whole project, rather than focusing on my own contributions.¹ As the maintainer, I try to look at every single LLDB PR, but my level of engagement varies. I expect there will be a subconscious bias towards the efforts I was involved in. If there’s an area of work I forgot to include here, more likely than not it’s because I forgot, not because I didn’t think it was important.

By the Numbers

I can confidently say that 2025 was an active year for LLDB. I counted 2489 commits in the lldb subdirectory from approximately 200 unique contributors. For comparison, in 2024 we had 1779 commits from 180 contributors. We had several new major contributors emerge that had a big impact on the project.

Debug Adapter Protocol

By far, the biggest focus area for 2025 was lldb-dap, our implementation of the Debug Adapter Protocol (DAP). We saw major architectural changes, the addition of missing and entirely new features, many quality-of-life improvements, and an increased focus on testing.

The majority of DAP requests were migrated from ad-hoc JSON parsing to strongly-typed C++ protocol structures. This not only improves maintainability, but it also helps with testing (fully covered by unit tests) and makes it easier to validate them against the spec.

The launch and attach flow was reworked several times to match the DAP specification. The respective request handlers now correctly defer responding until the configuration phase is complete.

Another notable change was the addition of a server mode. This allows multiple clients to share a single lldb-dap instance, significantly improving performance by allowing concurrent and subsequent debug sessions to share LLDB’s cached symbol data.

Various features were added or improved, including assembly and data breakpoints, memory and module events, external terminal support, and request cancellation.

The LLDB DAP Visual Studio extension now features expanded configuration options, launch URL support, and a module explorer. Nightly builds are automatically published to the Visual Studio Code Marketplace and the OpenVSX Registry.

Windows

Windows support improved significantly this year due to a renewed focus on the platform, compared to previous years where it was more a matter of “keeping the lights on”.

A huge achievement this year was the switch of the default PDB reader. We no longer have to rely on the Microsoft Debug Interface Access (DIA) SDK, which is only available on Windows. Instead, we use the “native” PDB reader, which uses LLVM’s PDB and CodeView support, allowing us to test PDB support on non-Windows platforms.

Various data formatters were added for MSVC’s STL implementation, bringing us closer to parity with libc++ and libstdc++.

Support was added for the Windows Virtual Console (ConPTY), enabling lldb-dap on Windows to correctly hook up standard input and output.

Data Inspection Language

The Data Inspection Language (DIL)² is an expression language designed to inspect program data (like variables) in a way that is consistent across different programming languages, but without executing code.

The DIL achieved a major milestone this year by becoming the default implementation for the frame variable command.

C++ Language Plugin & Expression Evaluator

The C++ language plugin and Clang type system saw a lot of changes this year. Most of the work was bug fixing and improvements to the foundation.

We changed how we perform function calls to correctly support ABI-tagged constructors and destructors. This means you can now call functions through a shared pointer in the expression evaluator.

A large effort centered around changing the way we print function names in backtraces, making them more user-friendly when working with heavily templated C++. The format is fully configurable.

WebAssembly

LLDB now supports full source-level debugging of WebAssembly: it can set breakpoints, show backtraces, and display variables when debugging supported runtimes.³ A new Wasm platform can be configured to launch binaries directly under the runtime.

Extensibility

LLDB’s extensibility is one of its defining strengths. This year we added two new capabilities to customize LLDB’s behavior.

The concept of a synthetic frame provider was added. This allows inserting or replacing stack frames with synthetic frames. When debugging an interpreter language calling native code, this can be used to replace runtime frames (e.g., Python) with frames to the interpreted language.

We also added a scripted breakpoint resolver. This allows you to create artificial stop locations, called facade locations. For the interpreter scenario mentioned above, this can be used to set a breakpoint in the interpreter runtime when a breakpoint is resolved, and to decide, by introspecting the runtime, whether a Python breakpoint is hit.

Python

LLDB restricted its usage of the Python API to the Limited C API. This is a first step towards removing the limitation that you can only import lldb into the same Python version that LLDB was linked against. However, more work is required to make that a reality.

Notable Mentions

• AIX support continued to make steady progress this year.
• A new vectorized memory read packet was added.
• Better RISC-V support with instruction emulation, support for 32-bit ELF core files and easier disassembling of unknown instructions.
• A customizable statusline was added to the command line driver.
• We became more diligent about writing release notes.

Conclusion

A lot has happened in 2025, much more than I was able to list here. I’m proud of everything the project has achieved this year, and I look forward to seeing what comes next. We have a healthy community that I’ve enjoyed working with tremendously. Thank you for all your hard work!