 | This articlemay rely excessively on sourcestoo closely associated with the subject, potentially preventing the article from beingverifiable andneutral. Please helpimprove it by replacing them with more appropriatecitations toreliable, independent sources.(February 2015) (Learn how and when to remove this message) |
| LLDB | |
|---|---|
 | |
| Developer | LLVM Developer Group |
| Stable release | |
| Written in | C++ |
| Operating system | macOS,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 |
| Repository | |
TheLLDB Debugger (LLDB) is thedebugger created byChris Lattner as a component of theLLVM project. It is built as a set of reusable components which extensively use existing libraries from LLVM, such as theClang expression parser and LLVMdisassembler. LLDB isfree and open-source software under theUniversity of Illinois/NCSA Open Source License,[3] aBSD-stylepermissive software license. Since v9.0.0, it was relicensed to theApache License 2.0 with LLVM Exceptions.[2]
LLDB supports debugging of programs written inC,Objective-C, andC++. TheSwift community maintains a version which adds support for the language.Free Pascal and theLazarus IDE can use LLDB as backend for their own FpDebug engine.
The LLDB debugger is known to work onmacOS,Linux,FreeBSD,NetBSD andWindows,[4] and supportsi386,x86-64, andARMinstruction sets.[5] LLDB is the default debugger forXcode 5 and later.Android Studio also uses LLDB for debug.[6] LLDB can be used from other IDEs, includingVisual Studio Code,[7]C++Builder,[8]Eclipse,[9] andCLion.[10]
| 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: | ? | N/a | | ? | N/a |
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" |
Consider the following incorrect program written inC:
#include<stdio.h>intmain(void){charmsg="Hello, world!\n";printf("%s",msg);return0;}
Using theclang compiler onmacOS, 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 namedtest.c, the command for thecompilation could be:
$clang-Wno-error=int-conversion-gtest.c-otest
And the binary can now be run:
$./testSegmentation fault
Since the example code, when executed, generates asegmentation 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 functionstrlen, but we can run abacktrace 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 withframe #5, LLDB indicates that the error is at line 5 oftest.c. Runningsource list, we see that this refers to the call toprintf. According to the exception codeEXC_BAD_ACCESS from the backtrace,strlen is trying to read from a region of memory it does not have access to bydereferencing an invalid pointer.[11] Returning to the source code, we see that the variablemsg is of typechar but contains a string instead of a character. To fix the problem, we modify the code to indicate thatmsg is apointer to a string ofchars 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 ofprintf to the screen. After the program exits normally, LLDB indicates that the process running the program has completed, and prints its exit status.
