LLDB

LLDB is an open-source debugger for developers working in C-family languages and LLVM-based toolchains. It suits programmers who want low-level control, scriptable APIs, or Xcode’s native debugging workflow. Its breadth is compelling, though Windows maturity and several Debug Adapter Protocol gaps deserve attention.

Overview

LLDB is a high-performance debugger assembled from reusable components, including LLVM’s disassembler and Clang’s expression parser. It can launch programs, attach to running processes, and work with breakpoints and watchpoints. Support for core dumps is useful when a live debugging session is not possible, but the absence of time-travel debugging rules it out for teams that depend on replaying earlier execution.

The project code uses the Apache 2.0 License with LLVM exceptions. LLDB is the default debugger in Xcode on macOS, while its documented targets include desktop, mobile, and BSD systems.

Key features

Debugging and expression evaluation

LLDB supports C, C++, and Objective-C debugging on desktop and iOS devices and simulators, with Objective-C++ also supported by its expression evaluator. Clang-based evaluation covers current language features and can handle multiline expressions; just-in-time evaluation is available where supported. That combination is useful for inspecting or manipulating program state in context, though JIT availability depends on the environment.

Conditional and exception breakpoints, watchpoints, process launch, and attachment cover the core control loop. LLDB also documents memory read and write, plus disassembly requests through lldb-dap. Its API supports symbolication and inspection of object and symbol files, extending its use beyond interactive sessions.

APIs and editor integration

A public object-oriented C++ API is exposed through a shared library, with Python bindings for scripting. Developers building tools or automating debugging workflows can use those interfaces without being limited to a single editor. The documentation also describes an integration using the Model Context Protocol.

For compatible editors and IDEs, lldb-dap presents LLDB through the Debug Adapter Protocol, including integrations for Visual Studio Code, Emacs, vim, and neovim. It supports function, conditional, data, and instruction breakpoints. However, it does not support step-back, setting a variable, goto-target, or terminate requests, so editor workflows needing those operations may be incomplete.

Remote debugging and configuration

LLDB documents remote debugging for Linux, Windows, Android, and iOS. For security reasons, it does not source a current-directory .lldbinit file by default; users relying on project-local initialization need to account for that behavior.

Pricing

LLDB costs free under its open-source plan, with no free trial. The free plan is the full project offering rather than a time-limited evaluation, making it suitable for individual developers and teams that can use its license and integrations. There are no paid tiers, seat counts, or quotas to weigh.

Platforms

The documented target platforms are macOS, iOS, tvOS, watchOS, Linux, FreeBSD, NetBSD, Windows, and Android. LLDB is the default debugger in Xcode on macOS, and it can debug C-family programs on iOS devices and simulators. Remote debugging extends to Linux, Windows, Android, and iOS.

Windows support remains under active development: basic functionality is expected to work, but ARM and AArch64 support is more experimental. Windows users targeting those architectures should treat LLDB as a less settled choice than users on its established platforms.

Who it's for

LLDB is a strong fit for C, C++, and Objective-C developers who want a free debugger with deep LLVM and Clang integration, especially those using Xcode or scripting through its APIs. It also suits developers building debugger-adjacent tools for symbolication, disassembly, or binary inspection.

It is less suitable when time-travel debugging is essential, when a workflow depends on unsupported lldb-dap requests, or when Windows ARM and AArch64 support must be mature. Its C-family focus also makes it a poor default for developers whose primary debugging needs fall outside those languages.

Pros and cons

• Pros: Free and open source under the Apache 2.0 License with LLVM exceptions, with no trial clock or paid tier.
• Pros: Clang-based expression evaluation and broad C-family debugging suit low-level development, including Apple-platform work.
• Pros: C++ and Python interfaces support custom tooling, scripting, and uses such as symbolication.
• Cons: No time-travel debugging, so it cannot replay prior program execution.
• Cons: lldb-dap omits step-back, variable-setting, goto-target, and terminate requests, which can restrict editor workflows.
• Cons: Windows is still under active development, with ARM and AArch64 specifically more experimental.

Alternatives

Browse the Debuggers category to compare options across the category.

• Delve is another free debugger for readers whose platform needs match its Linux, macOS, Windows, API, or self-hosted availability.
• IDA Pro is worth considering when disassembly and decompilation are the priority: IDA Free costs nothing and includes x86-32 and x86-64 disassembly plus two cloud-based decompilers; IDA Pro Essential is 1099.00 USD.
• Xdebug is a freemium alternative for readers seeking a debugger with Linux, macOS, Windows, web, or self-hosted platform availability. Its Pro plan is £200 a year and is for one developer.
• GDB is a free alternative for readers who want a debugger under the GNU General Public License with source code available.
• FlowStorm is a free and open-source option for readers whose platform needs fit Linux, Windows, or self-hosted use.
• RenderDoc is a free, MIT-licensed alternative for readers working on Android, Linux, or Windows.
• dnSpyEx is another free option for readers considering Linux or Windows.
• OpenOCD is another free option for readers considering Windows, macOS, or Linux.

Verdict

Choose LLDB if you need a capable, free C-family debugger with Clang expression evaluation, scriptable APIs, and a natural place in Xcode workflows. Look elsewhere if replay debugging is central, your editor depends on missing lldb-dap requests, or you need mature Windows ARM or AArch64 support.