Additional information

• Images
• Videos
• Documents
• Books
• Articles

Current state

LLDB supports debugging of programs written in C, Objective-C, and C++. The Swift community maintains a version which adds support for the language. Free Pascal and the Lazarus IDE can use LLDB as backend for their own FpDebug engine.

The LLDB debugger is known to work on macOS, Linux, FreeBSD, NetBSD and Windows,³ and supports i386, x86-64, and ARM instruction sets.⁴ LLDB is the default debugger for Xcode 5 and later. Android Studio also uses LLDB for debug.⁵ LLDB can be used from other IDEs, including Visual Studio Code,⁶ C++Builder,⁷ Eclipse,⁸ and CLion.⁹

Features matrix ¹⁰

Feature	FreeBSD	Linux	macOS	NetBSD	Windows
Backtracing
Breakpoints
C++11					?
Command-line lldb tool
Core file debugging
Debugserver (remote debugging)
Disassembly
Expression evaluation	Works with some bugs	Works with some bugs		Works with some bugs	Works with some bugs
JIT debugging	?	Symbolic debugging only	Untested	Work In Progress
Objective-C 2.0:	?	—		?	—

Examples of commands

lldb program	Debug "program" (from the shell)
run	Run the loaded program
break set -n main	Set a breakpoint at the start of function "main"
bt	Backtrace (in case the program crashed)
register read	Dump all registers
di -n main	Disassemble the function "main"

An example session

Consider the following incorrect program written in C:

#include <stdio.h> int main(void) { char msg = "Hello, world!\n"; printf("%s", msg); return 0; }

Using the clang compiler on macOS, the code above can be compiled using the -g flag to include appropriate debug information on the binary generated—including the source code—making it easier to inspect it using LLDB. Assuming that the file containing the code above is named test.c, the command for the compilation could be:

$ clang -Wno-error=int-conversion -g test.c -o test

And the binary can now be run:

$ ./test Segmentation fault

Since the example code, when executed, generates a segmentation fault, lldb can be used to inspect the problem:

$ lldb test (lldb) target create "test" Current executable set to 'test' (x86_64). (lldb) run Process 70716 launched: '/Users/wikipedia/test' (x86_64) Process 70716 stopped * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0xffffff90) frame #0: 0x00007fff6c7c46f2 libsystem_platform.dylib`_platform_strlen + 18 libsystem_platform.dylib`_platform_strlen: -> 0x7fff6c7c46f2 <+18>: pcmpeqb xmm0, xmmword ptr [rdi] 0x7fff6c7c46f6 <+22>: pmovmskb esi, xmm0 0x7fff6c7c46fa <+26>: and rcx, 0xf 0x7fff6c7c46fe <+30>: or rax, -0x1 Target 0: (test) stopped.

The problem occurs when calling the function strlen, but we can run a backtrace to identify the exact line of code that is causing the problem:

(lldb) bt * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0xffffff90) * frame #0: 0x00007fff6c7c46f2 libsystem_platform.dylib`_platform_strlen + 18 frame #1: 0x00007fff6c66b16a libsystem_c.dylib`__vfprintf + 8812 frame #2: 0x00007fff6c6911c3 libsystem_c.dylib`__v2printf + 475 frame #3: 0x00007fff6c668e22 libsystem_c.dylib`vfprintf_l + 54 frame #4: 0x00007fff6c666f72 libsystem_c.dylib`printf + 174 frame #5: 0x0000000100000f6d test`main at test.c:5:2 frame #6: 0x00007fff6c5dc3d5 libdyld.dylib`start + 1 (lldb) source list 3 int main(void) { 4 char msg = "Hello, world!\n"; 5 printf("%s", msg); 6 return 0; 7 }

From the line beginning with frame #5, LLDB indicates that the error is at line 5 of test.c. Running source list, we see that this refers to the call to printf. According to the exception code EXC_BAD_ACCESS from the backtrace, strlen is trying to read from a region of memory it does not have access to by dereferencing an invalid pointer.¹¹ Returning to the source code, we see that the variable msg is of type char but contains a string instead of a character. To fix the problem, we modify the code to indicate that msg is a pointer to a string of chars by adding the * operator:

#include <stdio.h> int main(void) { char* msg = "Hello, world!\n"; printf("%s", msg); return 0; }

After recompiling and running the executable again, LLDB now gives the correct result:

(lldb) target create "test" Current executable set to 'test' (x86_64). (lldb) run Process 93319 launched: '/Users/wikipedia/test' (x86_64) Hello, world! Process 93319 exited with status = 0 (0x00000000) (lldb)

LLDB runs the program, which prints the output of printf to the screen. After the program exits normally, LLDB indicates that the process running the program has completed, and prints its exit status.

See also

• Free and open-source software portal

• GNU Debugger
• Microsoft Visual Studio Debugger

External links

• Official website
• Supported LLDB Versions in Qt Creator

References

1. "LLVM Release License" http://llvm.org/releases/2.1/LICENSE.TXT ↩

2. LICENSE.TXT, llvm.org, retrieved 2019-09-24 https://releases.llvm.org/9.0.0/LICENSE.TXT ↩

3. "LLVM Project Blog". 20 January 2015. http://blog.llvm.org/2015/01/lldb-is-coming-to-windows.html ↩

4. "LLDB Status". Retrieved January 31, 2022. http://lldb.llvm.org/status/status.html ↩

5. "Debug your app". https://developer.android.com/studio/debug ↩

6. "Add a new tool named "lldb-vscode" that implements the Visual Studio Code Debug Adaptor Protocol". https://reviews.llvm.org/D50365 ↩

7. "11.3 introduces a new LLDB-based debugger for macOS Intel and 32-bit Android. With 11.3 all non-Windows platform debuggers across Delphi and C++ have moved to LLDB architecture". https://www.embarcadero.com/products/rad-studio/whats-new-in-11-alexandria ↩

8. "CDT/Useer/FAQ". https://wiki.eclipse.org/CDT/User/FAQ#How_do_I_debug_with_LLDB.3F ↩

9. "LLDB CLion Blog". 7 October 2024. https://blog.jetbrains.com/clion/tag/lldb/ ↩

10. "LLDB Status". Retrieved January 31, 2022. http://lldb.llvm.org/status/status.html ↩

11. "Technical Note TN2151: Understanding and Analyzing Application Crash Reports". Documentation Archive. Apple Developer. Retrieved 13 February 2020. https://developer.apple.com/library/archive/technotes/tn2151/_index.html#//apple_ref/doc/uid/DTS40008184-CH1-EXCEPTION_INFO-BAD_MEMORY_ACCESS__EXC_BAD_ACCESS____SIGSEGV____SIGBUS_ ↩