LLDB (debugger)

Last updated
LLDB
Developer(s) LLVM Developer Group
Stable release
18.1.5 [1]   OOjs UI icon edit-ltr-progressive.svg / 2 May 2024;21 days ago (2 May 2024)
Repository
Written in C++
Operating system macOS i386 and x86-64, Linux, FreeBSD, NetBSD, Windows
Type Debugger
License UIUC (BSD-style)
Apache License 2.0 with LLVM Exceptions (v9.0.0 or later) [2]
Website lldb.llvm.org

The LLDB Debugger (LLDB) is the debugger component of the LLVM project. It is built as a set of reusable components which extensively use existing libraries from LLVM, such as the Clang expression parser and LLVM disassembler. LLDB is free and open-source software under the University of Illinois/NCSA Open Source License, [3] a BSD-style permissive software license. Since v9.0.0, it was relicensed to the Apache License 2.0 with LLVM Exceptions. [2]

Contents

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, [4] and supports i386, x86-64, and ARM instruction sets. [5] LLDB is the default debugger for Xcode 5 and later. Android Studio also uses LLDB for debug. [6] LLDB can be used from other IDEs, including Visual Studio Code, [7] C++Builder, [8] Eclipse, [9] and CLion. [10]

Features matrix [5]
Feature FreeBSD Linux macOS NetBSD Windows
BacktracingYes check.svgYes check.svgYes check.svgYes check.svgYes check.svg
Breakpoints Yes check.svgYes check.svgYes check.svgYes check.svgYes check.svg
C++11 Yes check.svgYes check.svgYes check.svgYes check.svg ?
Command-line lldb toolYes check.svgYes check.svgYes check.svgYes check.svgYes check.svg
Core file debuggingYes check.svgYes check.svgYes check.svgYes check.svgYes check.svg
Debugserver (remote debugging)Yes check.svgYes check.svgYes check.svgYes check.svgDark Red x.svg
Disassembly Yes check.svgYes check.svgYes check.svgYes check.svgYes check.svg
Expression evaluation Works with some bugsWorks with some bugsYes check.svgWorks with some bugsWorks with some bugs
JIT debugging ?Symbolic debugging onlyUntestedWork In ProgressDark Red x.svg
Objective-C 2.0: ?Yes check.svg ?

Examples of commands

lldb programDebug "program" (from the shell)
runRun the loaded program
break set -n mainSet a breakpoint at the start of function "main"
bt Backtrace (in case the program crashed)
register readDump all registers
di -n mainDisassemble the function "main"

An example session

Consider the following incorrect program written in C:

#include<stdio.h>intmain(void){charmsg="Hello, world!\n";printf("%s",msg);return0;}

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-gtest.c-otest

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:

$ lldbtest(lldb)target create "test"Current executable set to 'test' (x86_64).(lldb)runProcess 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 + 18libsystem_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, -0x1Target 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. [11] 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>intmain(void){char*msg="Hello, world!\n";printf("%s",msg);return0;}

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)runProcess 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

Related Research Articles

<span class="mw-page-title-main">GNU Debugger</span> Source-level debugger

The GNU Debugger (GDB) is a portable debugger that runs on many Unix-like systems and works for many programming languages, including Ada, Assembly, C, C++, D, Fortran, Haskell, Go, Objective-C, OpenCL C, Modula-2, Pascal, Rust, and partially others.

In computing, a segmentation fault or access violation is a fault, or failure condition, raised by hardware with memory protection, notifying an operating system (OS) the software has attempted to access a restricted area of memory. On standard x86 computers, this is a form of general protection fault. The operating system kernel will, in response, usually perform some corrective action, generally passing the fault on to the offending process by sending the process a signal. Processes can in some cases install a custom signal handler, allowing them to recover on their own, but otherwise the OS default signal handler is used, generally causing abnormal termination of the process, and sometimes a core dump.

x86 assembly language is the name for the family of assembly languages which provide some level of backward compatibility with CPUs back to the Intel 8008 microprocessor, which was launched in April 1972. It is used to produce object code for the x86 class of processors.

<span class="mw-page-title-main">D (programming language)</span> Multi-paradigm system programming language

D, also known as dlang, is a multi-paradigm system programming language created by Walter Bright at Digital Mars and released in 2001. Andrei Alexandrescu joined the design and development effort in 2007. Though it originated as a re-engineering of C++, D is now a very different language drawing inspiration from other high-level programming languages, notably Java, Python, Ruby, C#, and Eiffel.

<span class="mw-page-title-main">OpenMP</span> Open standard for parallelizing

OpenMP is an application programming interface (API) that supports multi-platform shared-memory multiprocessing programming in C, C++, and Fortran, on many platforms, instruction-set architectures and operating systems, including Solaris, AIX, FreeBSD, HP-UX, Linux, macOS, and Windows. It consists of a set of compiler directives, library routines, and environment variables that influence run-time behavior.

Splint, short for Secure Programming Lint, is a programming tool for statically checking C programs for security vulnerabilities and coding mistakes. Formerly called LCLint, it is a modern version of the Unix lint tool.

In computing, POSIX Threads, commonly known as pthreads, is an execution model that exists independently from a programming language, as well as a parallel execution model. It allows a program to control multiple different flows of work that overlap in time. Each flow of work is referred to as a thread, and creation and control over these flows is achieved by making calls to the POSIX Threads API. POSIX Threads is an API defined by the Institute of Electrical and Electronics Engineers (IEEE) standard POSIX.1c, Threads extensions .

<span class="mw-page-title-main">LLVM</span> Compiler backend for multiple programming languages

LLVM is a set of compiler and toolchain technologies that can be used to develop a frontend for any programming language and a backend for any instruction set architecture. LLVM is designed around a language-independent intermediate representation (IR) that serves as a portable, high-level assembly language that can be optimized with a variety of transformations over multiple passes. The name LLVM originally stood for Low Level Virtual Machine, though the project has expanded and the name is no longer officially an initialism.

A variadic macro is a feature of some computer programming languages, especially the C preprocessor, whereby a macro may be declared to accept a varying number of arguments.

gtkmm is the official C++ interface for the popular GUI library GTK. gtkmm is free software distributed under the GNU Lesser General Public License (LGPL).

<span class="mw-page-title-main">Code::Blocks</span> Free, open source, cross-platform IDE

Code::Blocks is a free, open-source, cross-platform IDE that supports multiple compilers including GCC, Clang and Visual C++. It is developed in C++ using wxWidgets as the GUI toolkit. Using a plugin architecture, its capabilities and features are defined by the provided plugins. Currently, Code::Blocks is oriented towards C, C++, and Fortran. It has a custom build system and optional Make support.

Clang is a compiler front end for the C, C++, Objective-C, and Objective-C++ programming languages, as well as the OpenMP, OpenCL, RenderScript, CUDA, SYCL, and HIP frameworks. It acts as a drop-in replacement for the GNU Compiler Collection (GCC), supporting most of its compilation flags and unofficial language extensions. It includes a static analyzer, and several code analysis tools.

<span class="mw-page-title-main">Vala (programming language)</span> Programming language

Vala is an object-oriented programming language with a self-hosting compiler that generates C code and uses the GObject system.

Christopher Arthur Lattner is an American computer scientist and creator of LLVM, the Clang compiler, the Swift programming language and the MLIR compiler infrastructure.

Blocks are a non-standard extension added by Apple Inc. to Clang's implementations of the C, C++, and Objective-C programming languages that uses a lambda expression-like syntax to create closures within these languages. Blocks are supported for programs developed for Mac OS X 10.6+ and iOS 4.0+, although third-party runtimes allow use on Mac OS X 10.5 and iOS 2.2+ and non-Apple systems.

Bionic is an implementation of the standard C library, developed by Google for its Android operating system. It differs from the GNU C Library (glibc) in being designed for devices with less memory and processor power than a typical Linux system. It is a combination of new code and code from FreeBSD, NetBSD, and OpenBSD released under a BSD license, rather than glibc, which uses the GNU Lesser General Public License. This difference was important in the early days of Android, when static linking was common, and since bionic has its own ABI, it can't be replaced by a different libc without breaking all existing apps.

Objective-C is a high-level general-purpose, object-oriented programming language that adds Smalltalk-style messaging to the C programming language. Originally developed by Brad Cox and Tom Love in the early 1980s, it was selected by NeXT for its NeXTSTEP operating system. Due to Apple macOS’s direct lineage from NeXTSTEP, Objective-C was the standard programming language used, supported, and promoted by Apple for developing macOS and iOS applications until the introduction of the Swift programming language in 2014.

A code sanitizer is a programming tool that detects bugs in the form of undefined or suspicious behavior by a compiler inserting instrumentation code at runtime. The class of tools was first introduced by Google's AddressSanitizer of 2012, which uses directly mapped shadow memory to detect memory corruption such as buffer overflows or accesses to a dangling pointer (use-after-free).

<span class="mw-page-title-main">Zig (programming language)</span> A general-purpose programming language, toolchain to build Zig/C/C++ code

Zig is an imperative, general-purpose, statically typed, compiled system programming language designed by Andrew Kelley. It is intended as a successor to the language C, with the intent of being even smaller and simpler to program in, while offering more function. It is free and open-source software, released under an MIT License.

References

  1. "Release 18.1.5". 2 May 2024. Retrieved 16 May 2024.
  2. 1 2 LICENSE.TXT, llvm.org, retrieved 2019-09-24
  3. "LLVM Release License"
  4. "LLVM Project Blog". 20 January 2015.
  5. 1 2 "LLDB Status" . Retrieved January 31, 2022.
  6. "Debug your app".
  7. "Add a new tool named "lldb-vscode" that implements the Visual Studio Code Debug Adaptor Protocol".
  8. "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".
  9. "CDT/Useer/FAQ".
  10. "LLDB CLion Blog".
  11. "Technical Note TN2151: Understanding and Analyzing Application Crash Reports". Documentation Archive. Apple Developer. Retrieved 13 February 2020.