About LLDB and Xcode
With the release of Xcode 5, the LLDB debugger becomes the foundation of the debugging experience on OS X.
LLDB is Apple’s “scratch from scratch” alternative to GDB. Developed in close conjunction with the LLVM compiler, LLDB brings you state-of-the-art debugging as well as extensive functionality for flow control and data checking. Starting with Xcode 5, all new and pre-existing development projects are automatically reconfigured to use LLDB.
The standard LLDB installation provides you with an extensive set of commands designed to be compatible with familiar GDB commands. In addition to using standard configurations, you can easily customize the LLDB to suit your needs.
At a Glance
LLDB is fully integrated with Xcode 5 for source code development and build and run debugging experiences. You can access the rich functionality of Xcode UI using the controls provided and commands issued from the Xcode debug console.
Understand LLDB Basics to Unlock Advanced Features
With the LLDB command language, you can use the advanced features of LLDB. Command syntax rules and easy to learn. Many commands are expressed via included shortcuts that save you time and keystrokes. And you can use LLDB to help the system quickly examine and learn the details of existing commands, shortcuts, and command options.
You can use the command alias function to customize LLDB. You can also extend LLDB by using Python scripts and the Python-llDB object library.
Relevant Chapter: Getting Started with LLDB
Use LLDB Equivalents for Common GDB Commands (Use LLDB Equivalents instead of Common GDB Commands)
LLDB includes many of the same command aliases as GDB commands when delivered. If you already have experience with GDB commands, you can use the tables provided to look up GDB commands and find LLDB equivalents, both canonical and shorthand.
Relevant Chapter: GDB and LLDB Command Examples
Standalone LLDB Workflow
You typically experience LLDB by using Xcode debugging capabilities and issuing LLDB commands using the Xcode console. However, for open source and other non-GUi-based application debugging development, you can use LLDB as a traditional command-line debugger from a terminal window.
Understanding how LLDB works as a command-line debugger can also help you understand and use the full capabilities of LLDB from the Xcode console.
Relevant Chapter: Using LLDB as a Standalone Debugger
See Also
To learn more about how to use Xcode’s debugging features, all of which are supported by the LLDB debugging engine, see WWDC 2013 Session Video for Tools #407 WWDC 2013: Was Debugging with Xcode.
WWDC 2013 session Video for Tools #413 WWDC 2013: Advanced Debugging with LLDB to see the latest Advanced technologies to help you effectively track LLDB errors, see WWDC 2013 Session Video for Tools #413 WWDC 2013: Advanced Debugging with LLDB.
For more information about using LLDB Python scripts and other advanced features, visit The LLDB Debugger.
Getting Started with LLDB
LLDB is a command-line debugging environment that functions like GDB. LLDB provides an underlying debug environment for Xcode, including a console in the debug area for direct access to LLDB commands in the Xcode IDE environment.
This chapter briefly explains the LLDB syntax and command functions, tells you how to use the command alias function, and introduces you to the LLDB help system.
LLDB Command Structure
All users who start using LLDB should understand the LLDB command structure and syntax in order to realize the potential of LLDB and how to get the most out of it. In many cases, LLDB provides commands such as list and b that work like GDB commands and make LLDB easier for experienced GDB users to learn.
Understanding Command Syntax
The LLDB command syntax is structured and regular throughout. LLDB commands are of the following forms:
<command> [<subcommand> [<subcommand>...]] <action> [-options [option-value]] [argument [argument...]]
Copy the codeCommands and subcommands are the names of LLDB debugger objects. Commands and subcommands are arranged in a hierarchy: a particular command object creates context for the subcommand object that follows it, which in turn provides context for the next subcommand, and so on. Action is the object you want to combine in the debugger (it is preceded by command subcommand.. The operation performed in the context of entity. Options are action modifiers, usually with a value. Parameters represent various things, depending on the context of the command being used. For example, using the process launch command, the parameters in this context are what you enter on the command line, just as if you were calling the process outside of a debug session.
LLDB command line parsing is completed before command execution. Commands, subcommands, options, option values, and arguments are all separated by Spaces, Double quotes protect Spaces in option values and arguments. If you need to place a backslash or double quotation mark in an argument, add a backslash before the character in the argument. LLDB uses both single and double quotation marks equivalents, allowing for easy writing of the double quotation part of the command line. Such as:
(lldb) command [subcommand] -option "some \"quoted\" string"
Copy the codeIt can also be written as:
(lldb) command [subcommand] -option 'some "quoted" string'
Copy the codeThis command parsing design helps to unify the LLDB command syntax for all commands. (For GDB users, this also means that you may have to reference some parameters in the LLDB that you don’t have to reference in GDB.)
As an example of a simple LLDB command, to set a breakpoint at line 12 of the file test.c, type:
(lldb) breakpoint set --file test.c --line 12
Copy the codeCommands that seem to differ from this model (for example, print or b) are often custom Command forms created by the Command aliasing mechanism, as discussed in the Command Aliases and Help section below.
Using Command Options
Command options in the LLDB are in canonical (also known as “discoverable”) form and abbreviated form. For example, here is a partial list of command options for the breakpoint set command, with the canonical form in parentheses:
breakpoint set -M <method> ( --method <method> ) -S <selector> ( --selector <selector> ) -b <function-name> ( --basename <function-name> ) -f <filename> ( --file <filename> ) -l <linenum> ( --line <linenum> ) -n <function-name> ( --name The < XSL: - name >)...Copy the codeOptions can be placed in any order on the command line following a command. If the argument begins with a hyphen (-), indicate to the LLDB that you have completed the options for the current command by adding an option termination signal: a double hyphen (–). For example, if you want to start a process with the –stop-at-entry option for the process launch command and want to start the same process with the -program_arg_1 and -program_arg_2 values, type:
(lldb) process launch --stop-at-entry -- -program_arg_1 value -program_arg_2 value
Copy the codeUsing Raw Commands
The LLDB command parser supports “raw” commands, where the rest of the command string is passed to the command unexplained after the command option is removed. This is handy for commands whose arguments may be complex expressions that are unwieldy to protect with backslashes. For example, the expression command is a primitive command.
When you look for a command through help, the output of the command tells you if the command is original so you know what to expect.
Raw commands can still have options, if you have dashes in your command string, you can indicate that these are not option flags by placing option terminations (–) after the command name but before the command string.
Using Command Completion in LLDB
LLDB supports command completion of source file names, symbol names, and file names. Start completion in a terminal window by entering tabs on the command line. Completion in the Xcode console works the same way as completion in the source editor: completion pops up automatically after typing the third character, and the completion popup can be invoked manually by using the Esc (Escape) key. Additionally, completion in the Xcode console follows the Xcode Text Editing preference specified in the Editing panel.
Each option in a command can have a different completion character. For example, the –file
Comparing LLDB with GDB
The command line parsing and uniformity of the LLDB command parser is different when LLDB is used compared to GDB. The LLDB command syntax sometimes forces you to be more explicit about your intentions, but it is more conventional in use.
For example, setting breakpoints is a common operation. In GDB, to set a breakpoint, you can type the following to break foo.c at line 12:
(gdb) break foo.c:12
Copy the codeYou can interrupt function foo by typing the following:
(gdb) break foo
Copy the codeMore complex break expressions can be used in GDB. For example: (GDB) break foo.c::foo, which means: “Set a breakpoint in function foo in file foo.c”. But at some point, the GDB syntax becomes complex and limits the power of GDB, especially in C++, where there may be no reliable way to specify which function to break. These defects occur because the GDB command line syntax is supported by a special set of possibly contradictory expression parsers.
By contrast, LLDB breakpoint (breakpoint) commands require only a simple, straightforward method in their expressions, and provide the benefits of intelligent auto-completion as well as the ability to set breakpoints in more complex cases. To set the same file and line breakpoints in the LLDB, type:
(lldb) breakpoint set --file foo.c --line 12
Copy the codeTo set a breakpoint on a function named foo in the LLDB, type:
(lldb) breakpoint set --name foo
Copy the codeSetting breakpoints by name is more powerful in LLDB than in GDB because you can specify that you want to set breakpoints on functions by method name. To set breakpoints on all C++ methods named foo, type:
(lldb) breakpoint set --method foo
Copy the codeTo set a breakpoint on an Objective-C selector called alignLeftEdges: type:
(lldb) breakpoint set --selector alignLeftEdges:
Copy the codeYou can use the –shlib
(lldb) breakpoint set --shlib foo.dylib --name foo
Copy the codeThe LLDB commands described in this section use a canonical form of discoverable command names and options, which can seem wordy. However, as in GDB, the LLDB command interpreter does the shortest unique string match for command names, creating an abbreviated command form. For example, the following two command-line expressions demonstrate the same command:
(lldb) breakpoint set --name "-[SKTGraphicView alignLeftEdges:]"
(lldb) br s --name "-[SKTGraphicView alignLeftEdges:]"
Copy the codeAlso, you can combine shortest unique string matching with the abbreviation option format to reduce keystrokes. Using both together can further reduce command-line expressions. Such as:
(lldb) breakpoint set --shlib foo.dylib --name foo
Copy the codeTo:
(lldb) br s -s foo.dylib -n foo
Copy the codeThese features with LLDB provide almost the same sense of “shorthand” and simplicity as with GDB. See the rest of the Breakpoint Commands and GDB and LLDB Command Examples for more Examples of how shortest unique string matching and using the abbreviated form option can save keystrokes.
Note: You can also use Command Aliases, as discussed in Command Aliases and Help, to make common command-line expressions easy to remember and enter with just a few keystrokes.
Scripting with Python
For advanced users, LLDB has a built-in Python interpreter that can be accessed using script commands. All functions of the debugger can be used as classes in the Python interpreter. Therefore, you can implement the more complex commands introduced in GDB with define by writing Python functions using the LLDB-Python library, then loading the scripts into a running session and accessing them using script commands. For more information about the LLDB-Python library, visit the LLDB Python Reference and SAMPLE LLDB Python scripts section of the LLDB Debugger website.
Command Aliases and Help
Now that you understand the LLDB syntax and command-line dynamics, turn your attention to two very useful LLDB features — command aliases and the help system.
Understanding Command Aliases
Use the command alias mechanism in LLDB to create aliases for common commands. For example, if you type repeatedly:
(lldb) breakpoint set --file foo.c --line 12
Copy the codeYou can construct aliases using the following command:
(lldb) command alias bfl breakpoint set -f %1 -l %2
Copy the codeIt allows you to type this command:
(lldb) bfl foo.c 12
Copy the codeBecause command aliases are useful in a variety of situations, you should be familiar with their construction. For a complete explanation of command alias construction, restrictions, and syntax, use the LLDB Help system. Input:
(lldb) help command alias
Copy the codeNote: In its default configuration, aliases for some common commands have been added to the LLDB (for example, step, Next, and continue), but no attempt has been made to build an exhaustive set of aliases. In the experience of the LLDB development team, it is more convenient to set basic commands to a unique one or two letters and then learn those sequences, rather than populate the namespace with lots of aliases and then have to type them.
However, users are free to customize the LLDB command set in any way they like. LLDB reads the file ~/.lldbinit on startup. This is a file that stores aliases created by using the Command alias command at definition time. LLDB helps the system read this initialization file and display aliases so you can easily remind yourself of what you’ve set. To see all the currently defined aliases and their definitions, use the help -a command and find the currently defined aliases at the end of the help output, starting with the following:
.The following is a list of your current command abbreviations (see 'help command alias' for more info):...Copy the codeUsing LLDB Help
Explore the LLDB Help system to understand more broadly what the LLDB must provide and to see the details of the LLDB command construction. Familiarity with the help command gives you access to a large number of command documents in a help system.
A simple call to the help command returns a list of all the top-level LLDB commands. For example, here is a partial listing:
(lldb) help
The following is a list of built-in, permanent debugger commands:
_regexp-attach -- Attach to a process id if in decimal, otherwise treat the
argument as a process name to attach to.
_regexp-break -- Set a breakpoint using a regular expression to specify the
location, where <linenum> is in decimal and <address> is
in hex.
_regexp-bt -- Show a backtrace. An optional argument is accepted; if
that argument is a number, it specifies the number of
frames to display. If that argument is 'all'Full backtraces of all threads are displayed.andSo forth...Copy the codeCalling help followed by any command lists the help entry for that command as well as any subcommands, options, and arguments. Call help […] by iterating over all commands. , you can traverse the entire LLDB command hierarchy.
When called with the option –show-aliases (-a for short), the help command display includes all current command aliases.
(lldb) help -a
Copy the codeNote: Help -a generates a list of all provided command aliases and GDB command mockups as well as any command aliases you define.
Important: One of the aliases included in the popular requirement is a weak emulation of the GDB break command. It doesn’t do everything the GDB break command does (for example, it doesn’t handle expressions like break foo.c::bar). Instead, it handles more common cases and makes the transition to LLDB easier for experienced GDB users. GDB interrupt emulation is also alias b by default, matching the GDB convention.
To learn and practice the native LLDB command set, these provided defaults place the GDB interrupt emulation in the same way as the rest of the LLDB breakpoint commands. In the general case of all command aliases, if you don’t like one of the aliases provided, or if it gets in the way, you can easily get rid of it. Using the GDB interrupt emulator alias B as an example, the following command removes the provided GDB B emulator alias:
(lldb) command unalias b
Copy the codeYou can also run:
(lldb) command alias b breakpoint
Copy the codeIt allows you to run native LLDB breakpoint commands using only B.
A more straightforward way to explore what is available in the LLDB is to use the apropos command: it searches for a word in the LLDB help document and dumps a summary help string for each matching command. Such as:
(lldb) apropos file
The following commands may relate to 'file':... log enable -- Enable loggingfor a single log channel.
memory read -- Read from the memory of the process being
debugged.
memory write -- Write to the memory of the process being
debugged.
platform process launch -- Launch a new process on a remote platform.
platform select -- Create a platform if needed and select it as
the current platform.
plugin load -- Import a dylib that implements an LLDB
plugin.
process launch -- Launch the executable in the debugger.
process load -- Load a shared library into the current
process.
source -- A set of commands forAccessing Source File Information...andSo forth...Copy the codeUse the help command with the command alias to see how they are constructed. For example, type the following command to view the provided description of the GDB B emulation and its implementation:
(LLDB) help b...'b' is an abbreviation for '_regexp-break'
Copy the codeAnother feature of the help command is shown by examining the break command add (for Setting Breakpoints). To demonstrate it, you should execute the command and check the help system results:
(lldb) help break command add
Add a set of commands to a breakpoint, to be executed whenever the breakpoint is hit.
Syntax: breakpoint command add <cmd-options> <breakpt-id>
etc...
Copy the codeThe command parameters specified in Angle brackets in the help output (for example,
) indicate that this parameter is a generic parameter type and can be queried for further help from the command system. In this case, to learn more about
, type:
(lldb) help <breakpt-id>
<breakpt-id> -- Breakpoint IDs consist major and minor numbers; the major
etc...
Copy the codeUsing help regularly and browsing the LLDB help documentation is a good way to familiarize yourself with the scope of LLDB functionality.
GDB and LLDB Command Examples
The table in this chapter lists the commonly used GDB commands and provides the equivalent LLDB commands and alternative forms. GDB compatibility aliases built into the LLDB are also listed.
Note that the full LLDB command name can be matched with a unique short format that can be used instead. For example, you can use BR SE instead of breakpoint set.
Execution Commands
| GDB | LLDB |
| Start a process with no parameters. | |
| (gdb) run (gdb) r |
(lldb) process launch (lldb) run (lldb) r |
| Start the process with parameters. | |
| (gdb) run (gdb) r |
(lldb) process launch — (lldb) r |
| Start process A. out with parameters 1, 2, and 3 instead of supplying args every time. | |
| % gdb –args a.out 1 2 3 (gdb) run . (gdb) run . |
% lldb — a.out 1 2 3 (lldb) run . (lldb) run . |
| Start a process with parameters in a new terminal window (OS X only). | |
| – | (lldb) process launch –tty — (lldb) pro la -t — |
| Start the process with parameters in the existing terminal window /dev/ttys006 (OS X only). | |
| – | (lldb) process launch –tty=/dev/ttys006 — (lldb) pro la -t/dev/ttys006 — |
| Set environment variables for the process before starting. | |
| (gdb) set env DEBUG 1 | (lldb) settings set target.env-vars DEBUG=1 (lldb) set se target.env-vars DEBUG=1 |
| Sets environment variables for the process and the startup process in a single command. | |
| (lldb) process launch -v DEBUG=1 | |
| Attach to the process whose process ID is 123. | |
| (gdb) attach 123 | (lldb) process attach –pid 123 (lldb) attach -p 123 |
| Attach to a process named A.out. | |
| (gdb) attach a.out | (lldb) process attach –name a.out (lldb) pro at -n a.out |
| Wait for a process named A.out to start and attach. | |
| (gdb) attach -waitfor a.out | (lldb) process attach –name a.out –waitfor (lldb) pro at -n a.out -w |
| Attach to a remote GDB protocol server running on system eorgadd, port 8000. | |
| (gdb) target remote eorgadd:8000 | (lldb) gdb-remote eorgadd:8000 |
| Attach to a remote GDB protocol server running on your local system, port 8000. | |
| (gdb) target remote localhost:8000 | (lldb) gdb-remote 8000 |
| Attach to the Darwin kernel in KDP mode on the eorgadd system. | |
| (gdb) kdp-reattach eorgadd | (lldb) kdp-remote eorgadd |
| Performs a source-level step in the currently selected thread. | |
| (gdb) step (gdb) s |
(lldb) thread step-in (lldb) step (lldb) s |
| Performs source-level step execution in the currently selected thread. | |
| (gdb) next (gdb) n |
(lldb) thread step-over (lldb) next (lldb) n |
| Performs an instruction level step in the currently selected thread. | |
| (gdb) stepi (gdb) si |
(lldb) thread step-inst (lldb) si |
| Performs instruction level step execution in the currently selected thread. | |
| (gdb) nexti (gdb) ni |
(lldb) thread step-inst-over (lldb) ni |
| Jumps out of the currently selected frame. | |
| (gdb) finish | (lldb) thread step-out (lldb) finish |
| Backtrace and Disassemble each stop. | |
| – | (lldb) target stop-hook add Enter your stop hook command(s). Type ‘DONE’ to end. > bt > disassemble –pc > DONE Stop hook #1 added. |
Breakpoint Commands
| GDB | LLDB |
| Set breakpoints on all functions named main. | |
| (gdb) break main | (lldb) breakpoint set –name main (lldb) br s -n main (lldb) b main |
| Set a breakpoint at line 12 of the file test.c. | |
| (gdb) break test.c:12 | (lldb) breakpoint set –file test.c –line 12 (lldb) br s -f test.c -l 12 (lldb) b test.c:12 |
| Set breakpoints on all C++ methods where basename is main. | |
| (gdb) break main (Note: This breaks any C function named main.) |
(lldb) breakpoint set –method main (lldb) br s -M main |
| Set a breakpoint at the Objective-C function -[NSString stringWithFormat:]. | |
| (gdb) break -[NSString stringWithFormat:] | (lldb) breakpoint set –name “-[NSString stringWithFormat:]” (lldb) b -[NSString stringWithFormat:] |
| Set breakpoints on all Objective-C methods with selector child count. | |
| (gdb) break count (Note: This breaks any C or C++ function named count.) |
(lldb) breakpoint set –selector count (lldb) br s -S count |
| The breakpoint is set by the regular expression on the function name. | |
| (gdb) rbreak regular-expression | (lldb) breakpoint set –regex regular-expression (lldb) br s -r regular-expression |
| Breakpoints are set through regular expressions for the source file content. | |
| (gdb) shell grep -e -n pattern source-file (gdb) break source-file:CopyLineNumbers |
(lldb) breakpoint set –source-pattern regular-expression –file SourceFile (lldb) br s -p regular-expression -f file |
| List all breakpoints. | |
| (gdb) info break | (lldb) breakpoint list (lldb) br l |
| Delete a breakpoint. | |
| (gdb) delete 1 | (lldb) breakpoint delete 1 (lldb) br del 1 |
Watchpoint Commands
| GDB | LLDB |
| Set Watchpoint on a variable when it is written. | |
| (gdb) watch global_var | (lldb) watchpoint set variable global_var (lldb) wa s v global_var |
| Set Watchpoint at the memory location when writing. | |
| (gdb) watch -location g_char_ptr | (lldb) watchpoint set expression — my_ptr (lldb) wa s e — my_ptr Note: If -x byte_size is not specified, the size of the region to monitor defaults to the pointer size. This command takes the “raw” input and returns an unsigned integer pointing to the beginning of the region as an expression, evaluated after the option terminator (–). |
| Set conditions on Watchpoint. | |
| – | (lldb) watch set var global (lldb) watchpoint modify -c ‘(global==5)’ c . bt * thread #1: tid = 0x1c03, 0x0000000100000ef5 a.out`modify + 21 at main.cpp:16, stop reason = watchpoint 1 frame #0: 0x0000000100000ef5 a.out`modify + 21 at main.cpp:16 frame #1: 0x0000000100000eac a.out`main + 108 at main.cpp:25 frame #2: 0x00007fff8ac9c7e1 libdyld.dylib`start + 1 (int32_t) global = 5 |
| List all watchpoints. | |
| (gdb) info break | (lldb) watchpoint list (lldb) watch l |
| Delete a Watchpoint. | |
| (gdb) delete 1 | (lldb) watchpoint delete 1 (lldb) watch del 1 |
Examining Variables
Frame here refers to the stack frame of the method, for example in -viewDidLoad below.
- (void)viewDidLoad {
[super viewDidLoad];
// Do any additional setup after loading the view.
int a = 123;
NSLog(@"%d", a);
}
// Set a breakpoint at NSLog, run the program, hit the breakpoint, enter LLDB debugging mode, use the following LLDB command to observe the print result:
(lldb) frame variable
(ViewController *) self = 0x00007fc39a00a600
(SEL) _cmd = "viewDidLoad"
(int) a = 123
(lldb) frame variable --no-args // Do not print function arguments
(int) a = 123
(lldb) frame variable --no-locals // Only function arguments are printed
(ViewController *) self = 0x00007fc39a00a600
(SEL) _cmd = "viewDidLoad"
(lldb)
Copy the code| GDB | LLDB |
| Displays the parameters and local variables of the current frame. | |
| (gdb) info args and (gdb) info locals |
(lldb) frame variable (lldb) fr v |
| Displays local variables for the current frame. | |
| (gdb) info locals | (lldb) frame variable –no-args (lldb) fr v -a |
| Displays the contents of the local variable bar. | |
| (gdb) p bar | (lldb) frame variable bar (lldb) fr v bar (lldb) p bar |
| Displays the contents of the local variable bar formatted in hexadecimal. | |
| (gdb) p/x bar | (lldb) frame variable –format x bar (lldb) fr v -f x bar |
| Displays the contents of the global variable baz. | |
| (gdb) p baz | (lldb) target variable baz (lldb) ta v baz |
| Displays global/static variables defined in the current source file. | |
| – | (lldb) target variable (lldb) ta v |
| The variables argc and argv are displayed at each stop. (Use Target stop-hook) | |
| (gdb) display argc (gdb) display argv |
(lldb) target stop-hook add –one-liner “frame variable argc argv” (lldb) ta st a -o “fr v argc argv” (lldb) display argc (lldb) display argv |
| The variables argc and argv are displayed only when stopped in a function named main. | |
| – | (lldb) target stop-hook add –name main –one-liner “frame variable argc argv” (lldb) ta st a -n main -o “fr v argc argv” |
| Display the variable *this only if you stop in a C class named MyClass. | |
| – | (lldb) target stop-hook add –classname MyClass –one-liner “frame variable *this” (lldb) ta st a -c MyClass -o “fr v *this” |
Evaluating Expressions
| GDB | LLDB |
| Evaluates the generalized expression in the current frame. | |
| (gdb) print (int) printf (“Print nine: %d.”, 4 + 5) Or, if you don’t want to see void return: (gdb) call (int) printf (“Print nine: %d.”, 4 + 5) |
(lldb) expr (int) printf (“Print nine: %d.”, 4 + 5) Or use print alias: (lldb) print (int) printf (“Print nine: %d.”, 4 + 5) |
| Create convenience variables and assign values to them. | |
| (gdb) set $foo = 5 (gdb) set variable $foo = 5 Or use the print command: (gdb) print $foo = 5 Or use the call command: (gdb) call $foo = 5 To specify the type of the variable: (gdb) set $foo = (unsigned int) 5 |
LLDB evaluates variable declaration expressions as you would write them in C: (lldb) expr unsigned int $foo = 5 |
| Prints an Objective-C description of the object. | |
| (gdb) po [SomeClass returnAnObject] | (lldb) expr -O — [SomeClass returnAnObject] Or use the po alias: (lldb) po [SomeClass returnAnObject] |
| Print the dynamic type of the result of the expression. | |
| (gdb) set print object 1 (gdb) p someCPPObjectPtrOrReference Note: Only for C++ objects. |
(lldb) expr -d run-target — [SomeClass returnAnObject] (lldb) expr -d run-target — someCPPObjectPtrOrReference Or set dynamic type printing as default: (lldb) settings set target.prefer-dynamic run-target |
| Call a function to stop at its breakpoint. | |
| (gdb) set unwindonsignal 0 (gdb) p function_with_a_breakpoint() |
(lldb) expr -u 0 — function_with_a_breakpoint() |
Examining Thread State
| GDB | LLDB |
| Displays the stack traceback for the current thread. | |
| (gdb) bt | (lldb) thread backtrace (lldb) bt |
| Displays stack tracebacks for all threads. | |
| (gdb) thread apply all bt | (lldb) thread backtrace all (lldb) bt all |
| Trace the first five frames of the current thread. | |
| (gdb) bt 5 | (lldb) thread backtrace -c 5 (lldb) bt 5 (lldb-169 and later) (lldb) bt -c 5 (lldb-168 and earlier) |
| Select different stack frames for the current thread by index. | |
| (gdb) frame 12 | (lldb) frame select 12 (lldb) fr s 12 (lldb) f 12 |
| Lists information about the currently selected frame in the current thread. | |
| – | (lldb) frame info |
| Select the stack frame that calls the current stack frame. | |
| (gdb) up | (lldb) up (lldb) frame select –relative=1 |
| Select the stack frame called by the current stack frame. (Next stack frame) | |
| (gdb) down | (lldb) down (lldb) frame select –relative=-1 (lldb) fr s -r-1 |
| Use relative offsets to select different stack frames. | |
| (gdb) up 2 (gdb) down 3 |
(lldb) frame select –relative 2 (lldb) fr s -r2 (lldb) frame select –relative -3 (lldb) fr s -r-3 |
| Registers The general-purpose registers of the current thread. | |
| (gdb) info registers | (lldb) register read |
| Writes the new decimal value 123 to the current thread register RAx. | |
| (gdb) p $rax = 123 | (lldb) register write rax 123 |
| Skip 8 bytes before the current program counter (that is, the PC register) (instruction pointer). (Current program count register PC moves 8 bytes to the next instruction) | |
| (gdb) jump *$pc+8 | (lldb) register write pc `$pc+8` The LLDB command uses the backplane to evaluate the expression and insert the scaling results. |
| Displays the general purpose register for the current thread in signed decimal (positive and negative) format. | |
| – | (lldb) register read –format i (lldb) re r -f i The LLDB now supports GDB shorthand format syntax, but no space is allowed after the command: (lldb) register read/d Note: LLDB tries to use the same format characters as printf(3) whenever possible. Type Help format to see a complete list of format specifiers. |
| Displays all registers in the collection of all registers for the current thread. | |
| (gdb) info all-registers | (lldb) register read –all (lldb) re r -a |
| Displays the values of registers named RAx, RSP, and RBP in the current thread. | |
| (gdb) info all-registers rax rsp rbp | (lldb) register read rax rsp rbp |
| Displays the value of a register named RAx in the current thread in binary format. | |
| (gdb) p/t $rax | (lldb) register read –format binary rax (lldb) re r -f b rax The LLDB now supports GDB shorthand format syntax, but no space is allowed after the command: (lldb) memory read/4xw 0xbffff3c0 (lldb) x/4xw 0xbffff3c0 (lldb) memory read –gdb-format 4xw 0xbffff3c0 |
| Read memory from the expression argv[0]. | |
| (gdb) x argv[0] | (lldb) memory read `argv[0]` Note that any command can use any expression backplane to scale the expression result (as long as target stops) with inline: (lldb) memory read –size `sizeof(int)` `argv[0]` |
| Read 512 bytes of memory from address 0xbffFF3C0 and save the result as a local file in text. | |
| (gdb) set logging on (gdb) set logging file /tmp/mem.txt (gdb) x/512bx 0xbffff3c0 (gdb) set logging off |
(lldb) memory read –outfile /tmp/mem.txt –count 512 0xbffff3c0 (lldb) me r -o/tmp/mem.txt -c512 0xbffff3c0 (lldb) me r -o/tmp/mem.txt -c512 0xbffff3c0 (lldb) x/512bx -o/tmp/mem.txt 0xbffff3c0 |
| Save binary memory data to a file starting at 0x1000 and ending at 0x2000. | |
| (gdb) dump memory /tmp/mem.bin 0x1000 0x2000 | (lldb) memory read –outfile /tmp/mem.bin –binary 0x1000 0x1200 (lldb) me r -o /tmp/mem.bin -b 0x1000 0x1200 |
| Disassemble Current function of current frame. (Prints the assembly instruction of the current function, pointing to the current position of that instruction.) | |
| (gdb) disassemble | (lldb) disassemble –frame (lldb) di -f |
| Assembles functions named main from all classes. | |
| (gdb) disassemble main | (lldb) disassemble –name main (lldb) di -n main |
| Disassemble an address range. Convert the code to assemble the specified address range. | |
| (gdb) disassemble 0x1eb8 0x1ec3 | (lldb) disassemble –start-address 0x1eb8 –end-address 0x1ec3 (lldb) di -s 0x1eb8 -e 0x1ec3 |
| Assembles 20 instructions from a given address. | |
| (gdb) x/20i 0x1eb8 | (lldb) disassemble –start-address 0x1eb8 –count 20 (lldb) di -s 0x1eb8 -c 20 |
| Displays a mixed source and disassembly of the current function for the current frame. (is to output the source code and output the corresponding assembly function) | |
| – | (lldb) disassemble –frame –mixed (lldb) di -f -m |
| Disassembles the current function of the current frame and displays opcode bytes. | |
| – | (lldb) disassemble –frame –bytes (lldb) di -f -b |
| Disassembles the current source line for the current frame. | |
| – | (lldb) disassemble –line (lldb) di -l |
Executable and Shared Library Query Commands
| GDB | LLDB |
| Lists the main executables and all associated shared libraries. | |
| (gdb) info shared | (lldb) image list |
| Look for information about the original address in the executable or any shared library. | |
| (gdb) info symbol 0x1ec4 | (lldb) image lookup –address 0x1ec4 (lldb) im loo -a 0x1ec4 |
| Searches the binary for functions that match the regular expression. | |
| (gdb) info function | This one finds debug symbols: (lldb) image lookup -r -n This one finds non-debug symbols: (lldb) image lookup -r -s Provides a list of binaries as a parameter to limit the search. |
| Look up address information only in A. out. | |
| – | (lldb) image lookup –address 0x1ec4 a.out (lldb) im loo -a 0x1ec4 a.out |
| Find information about type Point by name. | |
| (gdb) ptype Point | (lldb) image lookup –type Point (lldb) im loo -t Point |
| Dump all sections in the main executable and any shared library. | |
| (gdb) maintenance info sections | (lldb) image dump sections |
| Dump all sections of the A. out module | |
| – | (lldb) image dump sections a.out |
| Dump all symbols in the main executable and any shared library. | |
| – | (lldb) image dump symtab |
| Dump all symbols in a.out and liba.so | |
| – | (lldb) image dump symtab a.out liba.so |
Miscellaneous
| GDB | LLDB |
| Echo text on the screen. | |
| (gdb) echo Here is some text\n | (lldb) script print “Here is some text” |
| Remap the source file pathname for the debug session. | |
| (gdb) set pathname-substitutions /buildbot/path /my/path | (lldb) settings set target.source-map /buildbot/path /my/path Note: If your source files are no longer in the same location as when the program was build-perhaps the program was built on a different computer-you need to tell the debugger how to build the local file path instead of the system file path. |
| Provide a catchall directory to search for source files. | |
| (gdb) directory /my/path | (No equivalent command yet.) |
Using LLDB as a Standalone Debugger
This chapter describes the workflow and operations of debugging sessions based on a basic Terminal. Where appropriate, LLDB operations are compared to similar GDB operations.
In most cases, you use the LLDB debugger indirectly through the Xcode debugging function and issue LLDB commands using the Xcode console pane. But for open source and other non-GUi-based application debugging development, the LLDB is used as a traditional command-line debugger in the terminal window. To use LLDB as a command line debugger, you should know how to:
- Loading the debug process
- Attach the running process to the LLDB
- Set breakPoints and Watchpoints
- Control process execution
- Navigate through the debugged process
- Check the status and values of variables
- Implementing alternative Code
The Xcode IDE automates many of these operations by fully integrating the LLDB into source code editing, build, and “run for debugging” loops with graphical controls. Understanding how these operations work from the command line also helps you understand and use the full capabilities of the LLDB debugger in the Xcode console pane.
Specifying the Program to Debug
First, you need to set the program to debug. As with GDB, you can start LLDB and use the command line to specify which files to debug. Type:
$ lldb /Projects/Sketch/build/Debug/Sketch.app
Current executable set to '/Projects/Sketch/build/Debug/Sketch.app' (x86_64).
Copy the code
Alternatively, you can specify the executable to debug using the file command after the executable has already been run:
$ lldb
(lldb) file /Projects/Sketch/build/Debug/Sketch.app
Current executable set to '/Projects/Sketch/build/Debug/Sketch.app' (x86_64).
Copy the code
Setting Breakpoints
Next, you may want to set breakpoints to start debugging after the process starts. LLDB Command Structure briefly discusses setting breakpoints. To see all options for breakpoint Settings, use help Breakpoint set. For example, type the following to set a breakpoint when using any method called alignLeftEdges:
(lldb) breakpoint set --selector alignLeftEdges:
Breakpoint created: 1: name = 'alignLeftEdges:', locations = 1, resolved = 1
Copy the codeTo find out which breakpoints you set, type the breakpoint list command and check what it returns, as follows:
(lldb) breakpoint list
Current breakpoints:
1: name = 'alignLeftEdges:', locations = 1, resolved = 1
1.1: where = Sketch`-[SKTGraphicView alignLeftEdges:] + 33 at /Projects/Sketch/SKTGraphicView.m:1405, address = 0x0000000100010d5b, resolved, hit count = 0
Copy the code(Downloaded Sketch. App, tried it and found alignLeftEdges: This function no longer exists, then I checked the binary executable of Sketch with MachOView and found that the breakpoints for the custom selectors could not be found, but the breakpoints for the system library functions used by it could be added normally.
2: name = 'alignLeft:', locations = 6
2.1: where = WebKit`-[WKView alignLeft:], address = WebKit[0x00007fff3cad71f3], unresolved, hit count = 0
2.2: where = WebKit`-[WKWebView(WKImplementationMac) alignLeft:], address = WebKit[0x00007fff3cadb9f7], unresolved, hit count = 0
2.3: where = AppKit`-[NSText alignLeft:], address = AppKit[0x00007fff23320dbf], unresolved, hit count = 0
2.4: where = AppKit`-[NSTextView alignLeft:], address = AppKit[0x00007fff23348112], unresolved, hit count = 0
2.5: where = WebKitLegacy`-[WebHTMLView alignLeft:], address = WebKitLegacy[0x00007fff34fe7e60], unresolved, hit count = 0
2.6: where = WebKitLegacy`-[WebView(WebViewEditingActions) alignLeft:], address = WebKitLegacy[0x00007fff350025f0], unresolved, hit count = 0
Copy the code
In LLDB, breakpoints have two parts: the logical specification of the breakpoint, which is what the user provides to the Breakpoint set command, and the location in the code that matches that specification. For example, breaking by –selector sets a breakpoint on all methods that implement that selector in a class in a program. Similarly, file and line breakpoints can result in multiple locations if files and lines are included inline at different locations in the code.
One piece of information provided by the breakpoint list command output is the number of logical breakpoints, the class of each logical breakpoint, the specific memory address, and the number of hits. The two are separated by periods (.) Links, such as those in: 2: and 2.1:~2.6: above, indicate the number of roll breaks and breakpoints, and then everything in 2.1:~2.6:.
Because the logical breakpoint is still valid, if another shared library is loaded that contains alignLeftEdges: selector child implementation, the new location is added to breakpoint 1 (that is, 1.2 breakpoints are set on the newly loaded selector).
Another piece of information in the breakpoint list is whether the breakpoint location has been resolved. When the file address corresponding to a location is loaded into the program being debugged, it is resolved. For example, if you set a breakpoint in a shared library that you uninstall later, the breakpoint location is retained but not resolved. (Does this later uninstall mean using Dyld’s unmap to uninstall?)
LLDB acts like GDB with the command:
(gdb) set breakpoint pending on
Copy the codeLike GDB, LLDB always creates a breakpoint from your specification, even if it doesn’t find any matches to the specification (that is, it creates a breakpoint even if the code location where we want to break the point is not found). To determine if the expression has been resolved, check the position field using breakpoint List. When you set a breakpoint, LLDB reports the breakpoint as pending. By looking at breakpoints that are in a pending state, you can check the breakpoint set output to see if there were any misspellings when defining breakpoints without finding any locations. WARNING: Unable to resolve breakpoint to any actual locations. The location that tells us to break is nowhere to be found in the code.
(lldb) breakpoint set --file foo.c --line 12
Breakpoint created: 2: file ='foo.c', line = 12, locations = 0 (pending)
WARNING: Unable to resolve breakpoint to any actual locations.
Copy the codeYou can use the breakpoint-triggered commands to remove, disable, condition, and ignore counts at all locations where a logical breakpoint is generated, or at any particular location where a logical breakpoint is resolved. For example, if you want to add a command to print a traceback when the LLDB encounters a breakpoint numbered 1.1, execute the following command:
(lldb) breakpoint command add 1.1
Enter your debugger command(s). Type 'DONE' to end.
> bt
> DONE
Copy the codeBy default, breakpoint command add uses the LLDB command line command. To explicitly specify this default, pass the –command option (breakpoint command add –command…). . If you implement breakpoint commands using Python scripts, use the –script option. The LLDB helps the system have a lot of information to interpret breakpoint Command Add.
Setting Watchpoints
In addition to breakpoints, LLDB supports watchpoints to monitor variables without stopping the running process. Use help Watchpoint to view all commands for watchpoint operations. For example, enter the following command to monitor a variable named global for write operations and stop only if the condition (global==5) is true:
(lldb) watch set var global
Watchpoint created: Watchpoint 1: addr = 0x100001018 size = 4 state = enabled type = w
declare @ '/Volumes/data/lldb/svn/ToT/test/functionalities/watchpoint/watchpoint_commands/condition/main.cpp:12'
(lldb) watch modify -c '(global==5)'
(lldb) watch list
Current watchpoints:
Watchpoint 1: addr = 0x100001018 size = 4 state = enabled type = w
declare @ '/Volumes/data/lldb/svn/ToT/test/functionalities/watchpoint/watchpoint_commands/condition/main.cpp:12'
condition = '(global==5)'
(lldb) c
Process 15562 resuming
(lldb) about to write to 'global'. Process15562 stopped and was programmatically restarted.
Process 15562 stopped and was programmatically restarted.
Process 15562 stopped and was programmatically restarted.
Process 15562 stopped and was programmatically restarted.
Process 15562 stopped
* thread #1: tid = 0x1c03.0x0000000100000ef5 a.out`modify + 21 at main.cpp:16, stop reason = watchpoint 1
frame #0: 0x0000000100000ef5 a.out`modify + 21 at main.cpp:16
13
14 static void modify(int32_t &var) {
15 ++var;
-> 16 }
17
18 int main(int argc, char** argv) {
19 int local = 0;
(lldb) bt
* thread #1: tid = 0x1c03.0x0000000100000ef5 a.out`modify + 21 at main.cpp:16, stop reason = watchpoint 1
frame #0: 0x0000000100000ef5 a.out`modify + 21 at main.cpp:16
frame #1: 0x0000000100000eac a.out`main + 108 at main.cpp:25
frame #2: 0x00007fff8ac9c7e1 libdyld.dylib`start + 1
(lldb) frame var global
(int32_t) global = 5
(lldb) watch list -v
Current watchpoints:
Watchpoint 1: addr = 0x100001018 size = 4 state = enabled type = w
declare @ '/Volumes/data/lldb/svn/ToT/test/functionalities/watchpoint/watchpoint_commands/condition/main.cpp:12'
condition = '(global==5)'
hw_index = 0 hit_count = 5 ignore_count = 0
(lldb)
Copy the codeLaunching the Program with LLDB
Once you have specified the program to debug and set a breakpoint to stop it at an interesting location, you need to start (or start) it into the running process. To start the LLDB program, use the Process launch command or one of its built-in aliases:
(lldb) process launch
(lldb) run
(lldb) r
Copy the codeYou can also attach the LLDB to an already running process (the process that runs the executable file you specified earlier) using the process ID or process name. LLDB supports the –waitfor option when attaching to a process by name. This option tells the LLDB to wait for the next process with that name to appear and then attach to it. For example, here are the three commands attached to the Sketch process, assuming the process ID is 123:
(lldb) process attach --pid 123
(lldb) process attach --name Sketch
(lldb) process attach --name Sketch --waitfor
Copy the codeAfter you start or attach the LLDB to a process, the process may stop for some reason. Such as:
(lldb) process attach -p 12345
Process 46915 Attaching
Process 46915 Stopped
1 of 3 threads stopped with reasons:
* thread #1: tid = 0x2c03.0x00007fff85cac76a, where = libSystem.B.dylib`__getdirentries64 + 10,
stop reason = signal = SIGSTOP, queue = com.apple.main-thread
Copy the codePlease note the line “1 of 3 threads Stopped with reasons:” and the line following it. In multithreaded environments, it is common for multiple threads to reach breakpoints before the kernel actually returns control to the debugger. In this case, you will see all the threads that were stopped due to the reasons listed in the stop message.
Controlling Your Program
Once started, the LLDB allows the program to continue running until a breakpoint is hit. The primitive commands for Process Control reside under the Thread command hierarchy. Here’s an example:
(lldb) thread continue
Resuming thread 0x2c03 in process 46915
Resuming process 46915
(lldb)
Copy the codeNote: In the current version (llDB-300.2.24), LLDB can only operate on one thread at a time, But its design supports saying “step over the function in Thread 1, and step into the function in Thread 2, and continue Thread 3”, and so on.
For convenience, all Stepping commands have simple aliases. For example, Thread continue can be called only with C, as can other stepper commands — they are very similar to those in GDB. Such as:
(lldb) thread step-in // The same as "step" or "s" in GDB.
(lldb) thread step-over // The same as "next" or "n" in GDB.
(lldb) thread step-out // The same as "finish" or "f" in GDB.
Copy the codeBy default, LLDB defines aliases for all common GDB process control commands (for example, S, step, n, Next, Finish). If you find that the GDB process control commands you are used to don’t exist, you can use the command alias to add them to the ~/.lldbinit file.
LLDB also supports versions of the step by directive:
(lldb) thread step-inst // The same as "stepi" / "si" in GDB.
(lldb) thread step-over-inst // The same as "nexti" / "ni" in GDB.
Copy the codeLLDB runs until a line or frame exits step mode:
(lldb) thread until 100
Copy the codeThis command runs the thread until the current frame reaches line 100. If the code skips line 100 while running, execution stops when the frame pops off the stack. This command is very close to GDB’s until command.
By default, the LLDB shares the terminal with the process being debugged. In this mode, just like debugging with GDB, anything you type goes to the STDIN of the process being debugged while the process is running. To interrupt the process, type CTRL+C.
However, if you attach to or start a process with the –no-stdin option, the Command interpreter is always available to enter commands. Always having a (LLDB) prompt can be a little disconcerting for GDB users at first, but it’s useful. Use the –no-stdin option to set breakpoints, watch points, etc., without explicitly breaking the program being debugged:
(lldb) process continue
(lldb) breakpoint set --name stop_here
Copy the codeThere are many LLDB commands that will not work when the process being debugged is running: the command interpreter will let you know when the command is inappropriate in most cases. (If you find that the command interpreter does not mark any instances of the problem case, please submit the error: bugreport.apple.com.)
Play a role in the process of runtime commands include suspended interrupt process (process interrupt), obtain process state (the process status), breakpoint set and clear (breakpoint [set | clear | enable | disable | list]… ) [read and read and write memory (memory | write]…). .
The topic of disabling STDIN for processes running in the LLDB provides a good opportunity to show how to set debugger properties. For example, if you always want to run in –no-stdin mode, use the LLDB Settings command to set it as a generic process property. The LLDB Settings command is equivalent to the GDB set command. To do this, type:
(lldb) settings set target.process.disable-stdio true
Copy the codeIn the LLDB, Settings are organized hierarchically so that you can easily discover them. In addition, almost anywhere you can specify Settings on general-purpose entities, such as Threads, you can also apply this option to specific instances. Use the Settings list command to view the current LLDB Settings. You can use the help Settings command to learn more about how the Settings command works.
Examining Thread State
When the process stops, the LLDB selects the current thread and the current frame in that thread (which is always the bottommost frame when stopped). Many of the commands used to check status work on the current thread or frame.
To check the current state of the process, start with the following thread:
(lldb) thread list
Process 46915 state is Stopped
* thread #1: tid = 0x2c03.0x00007fff85cac76a, where = libSystem.B.dylib`__getdirentries64 + 10, stop reason = signal = SIGSTOP, queue = com.apple.main-thread
thread #2: tid = 0x2e03.0x00007fff85cbb08a, where = libSystem.B.dylib`kevent + 10, queue = com.apple.libdispatch-manager
thread #3: tid = 0x2f03.0x00007fff85cbbeaa, where = libSystem.B.dylib`__workq_kernreturn + 10
Copy the codeThe asterisk (*) indicates that Thread #1 is the current thread. To get a trace for this thread, type the thread backtrace command:
(lldb) thread backtrace
thread #1: tid = 0x2c03, stop reason = breakpoint 1.1, queue = com.apple.main-thread
frame #0: 0x0000000100010d5b, where = Sketch`-[SKTGraphicView alignLeftEdges:] + 33 at /Projects/Sketch/SKTGraphicView.m:1405
frame #1: 0x00007fff8602d152, where = AppKit`-[NSApplication sendAction:to:from:] + 95
frame #2: 0x00007fff860516be, where = AppKit`-[NSMenuItem _corePerformAction] + 365
frame #3: 0x00007fff86051428, where = AppKit`-[NSCarbonMenuImpl performActionWithHighlightingForItemAtIndex:] + 121
frame #4: 0x00007fff860370c1, where = AppKit`-[NSMenu performKeyEquivalent:] + 272
frame #5: 0x00007fff86035e69, where = AppKit`-[NSApplication _handleKeyEquivalent:] + 559
frame #6: 0x00007fff85f06aa1, where = AppKit`-[NSApplication sendEvent:] + 3630
frame #7: 0x00007fff85e9d922, where = AppKit`-[NSApplication run] + 474
frame #8: 0x00007fff85e965f8, where = AppKit`NSApplicationMain + 364
frame #9: 0x0000000100015ae3, where = Sketch`main + 33 at /Projects/Sketch/SKTMain.m:11
frame #10: 0x0000000100000f20, where = Sketch`start + 52
Copy the codeProvide a list of threads to trace, or use the keyword all to see all threads.
(lldb) thread backtrace all
Copy the codeUse the thread select command to set the selected thread, which will be used by default in all commands in the next section, where the thread index is the thread index shown in the Thread list, using:
(lldb) thread select 2
Copy the codeExamining the Stack Frame State
The most convenient way to check frame parameters and local variables is to use the frame variable command. (Frame can be understood as a breakpoint on a line of a function, and the program hits the breakpoint, the execution state, the state of the entire register, and the state of the stack frame of the current function.)
(lldb) frame variable
self = (SKTGraphicView *) 0x0000000100208b40
_cmd = (struct objc_selector *) 0x000000010001bae1
sender = (id) 0x00000001001264e0
selection = (NSArray *) 0x00000001001264e0
i = (NSUInteger) 0x00000001001264e0
c = (NSUInteger) 0x00000001001253b0
Copy the codeIf no variable name is specified, all parameters and local variables are displayed. If you call frame variable, passing in the name or names of specific local variables, only those variables will be printed. Such as:
(lldb) frame variable self
(SKTGraphicView *) self = 0x0000000100208b40
Copy the codeYou can pass the path to a child element of one of the available local variables and then print that child element. Such as:
(lldb) frame variable self.isa
(struct objc_class *) self.isa = 0x0000000100023730
Copy the codeThe frame variable command is not a complete expression parser, but it does support simple operations such as &, *, ->, [] (no overloaded operators). Array parentheses can be used on Pointers to treat them as arrays. Such as:
(lldb) frame variable *self
(SKTGraphicView *) self = 0x0000000100208b40
(NSView) NSView = {
(NSResponder) NSResponder = {
...
(lldb) frame variable &self
(SKTGraphicView **) &self = 0x0000000100304ab
(lldb) frame variable argv[0]
(char const *) argv[0] = 0x00007fff5fbffaf8 "/Projects/Sketch/build/Debug/Sketch.app/Contents/MacOS/Sketch"
Copy the codeThe frame variable command performs the “object Printing “operation on variables. Currently, LLDB supports objective-C printing only, using the description method of an object. Turn this on by passing the -o flag to frame Variable.
(lldb) frame variable -O self
(SKTGraphicView *) self = 0x0000000100208b40< SKTGraphicView:0x100208b40>
Copy the codeTo select another frame to view, use the frame Select command.
(lldb) frame select 9
frame #9: 0x0000000100015ae3, where = Sketch`function1 + 33 at /Projects/Sketch/SKTFunctions.m:11
Copy the codeTo move a process’s view up and down the stack, pass the –relative option (abbreviated -r). LLDB has built-in aliases U and D, which behave like their GDB equivalents.
To view more complex data or change program data, use the generic expression command. It takes an expression and evaluates it within the range of the currently selected frame. Such as:
(lldb) expr self
$0 = (SKTGraphicView *) 0x0000000100135430
(lldb) expr self = 0x00
$1 = (SKTGraphicView *) 0x0000000000000000
(lldb) frame var self
(SKTGraphicView *) self = 0x0000000000000000
Copy the codeExecuting Alternative Code
Expressions can also be used to call functions, as shown in the following example:
(lldb) expr (int) printf ("I have a pointer 0x%llx.\n", self)
$2 = (int) 22
I have a pointer 0x0.
Copy the codeThe expression command is one of the raw commands. Therefore, you don’t have to quote the entire expression or backslash protection quotes, etc.
The result of the expression is stored in persistent variables (of the form $[0-9]+), which you can use in further expressions, such as:
(lldb) expr self = $0
$4 = (SKTGraphicView *) 0x0000000100135430
Copy the codeRefer to the link
Reference link :🔗
- LLDB Quick Start Guide
- Advanced Debugging with Xcode and LLDB
- Xcode 10.2 Release Notes
- Little Stupid Wolf’s LLDB trick: Chisel
- How to debug more efficiently in iOS development: LLDB vs. Chisel
- Dancing with the debugger – the waltz of LLDB
- Chisel-lldb command plug-in to make debugging easier
- LLDB advanced debugging +Cycript
- IOS reverse LLDB debugging
- The LLDB command is commonly used for iOS debugging
- LLDB study notes
- Chisel for iOS debugging
- IOS debugging Advanced – More efficient use of Xcode and LLDB
- New feature added to LLDB in Xcode10.2