742 lines · plain
1Tutorial2========3 4This document describes how to use LLDB if you are already familiar with5GDB's command set. We will start with some details on LLDB command structure and6syntax.7 8Command Structure9-----------------10 11Unlike GDB's quite free-form commands, LLDB's are more structured. All commands12are of the form:13 14::15 16 <noun> <verb> [-options [option-value]] [argument [argument...]]17 18The command line parsing is done before command execution, so it is the same for19all commands. The command syntax for basic commands is very simple.20 21* Arguments, options and option values are all white-space separated.22* Either single ``'`` or double-quotes ``"`` (in pairs) are used to protect white-spaces23 in an argument.24* Escape backslashes and double quotes within arguments should be escaped25 with a backslash ``\``.26 27This makes LLDB's commands more regular, but it also means you may have to quote28some arguments in LLDB that you would not in GDB.29 30There is one other special quote character in LLDB - the backtick `````.31If you put backticks around an argument or option value, LLDB will run the text32of the value through the expression parser, and the result of the expression33will be passed to the command. So for instance, if ``len`` is a local34``int`` variable with the value ``5``, then the command:35 36::37 38 (lldb) memory read -c `len` 0x1234539 40Will receive the value ``5`` for the count option, rather than the string ``len``.41 42Options can be placed anywhere on the command line, but if the arguments begin43with a ``-`` then you have to tell LLDB that you are done with options for the44current command by adding an option termination: ``--``.45 46So for instance, if you want to launch a process and give the ``process launch``47command the ``--stop-at-entry`` option, yet you want the process you are about48to launch to be launched with the arguments ``-program_arg value``, you would type:49 50::51 52 (lldb) process launch --stop-at-entry -- -program_arg value53 54We also tried to reduce the number of special purpose argument parsers, which55sometimes forces the user to be explicit about their intentions. The first56instance you willl see of this is the breakpoint command. In GDB, to set a57breakpoint, you might enter:58 59::60 61 (gdb) break foo.c:1262 63To break at line ``12`` of ``foo.c``, and:64 65::66 67 (gdb) break foo68 69To break at the function ``foo``. As time went on, the parser that tells ``foo.c:12``70from ``foo`` from ``foo.c::foo`` (which means the function ``foo`` in the file ``foo.c``)71got more and more complex. Especially in C++ there are times where there is72really no way to specify the function you want to break on.73 74The LLDB commands are more verbose but also more precise and allow for75intelligent auto completion.76 77To set the same file and line breakpoint in LLDB you can enter either of:78 79::80 81 (lldb) breakpoint set --file foo.c --line 1282 (lldb) breakpoint set -f foo.c -l 1283 84To set a breakpoint on a function named ``foo`` in LLDB you can enter either of:85 86::87 88 (lldb) breakpoint set --name foo89 (lldb) breakpoint set -n foo90 91You can use the ``--name`` option multiple times to make a breakpoint on a set of92functions as well. This is convenient since it allows you to set common93conditions or commands without having to specify them multiple times:94 95::96 97 (lldb) breakpoint set --name foo --name bar98 99Setting breakpoints by name is even more specialized in LLDB as you can specify100that you want to set a breakpoint at a function by method name. To set a101breakpoint on all C++ methods named ``foo`` you can enter either of:102 103::104 105 (lldb) breakpoint set --method foo106 (lldb) breakpoint set -M foo107 108 109To set a breakpoint Objective-C selectors named ``alignLeftEdges:`` you can enter either of:110 111::112 113 (lldb) breakpoint set --selector alignLeftEdges:114 (lldb) breakpoint set -S alignLeftEdges:115 116You can limit any breakpoints to a specific executable image by using the117``--shlib <path>`` (``-s <path>`` for short):118 119::120 121 (lldb) breakpoint set --shlib foo.dylib --name foo122 (lldb) breakpoint set -s foo.dylib -n foo123 124The ``--shlib`` option can also be repeated to specify several shared libraries.125 126Suggestions on more interesting primitives of this sort are also very welcome.127 128Just like GDB, the LLDB command interpreter does a shortest unique string match129on command names, so the following two commands will both execute the same130command:131 132::133 134 (lldb) breakpoint set -n "-[SKTGraphicView alignLeftEdges:]"135 (lldb) br s -n "-[SKTGraphicView alignLeftEdges:]"136 137LLDB also supports command completion for source file names, symbol names, file138names, etc. Completion is initiated by hitting TAB. Individual options in a139command can have different completers, so for instance, the ``--file <path>``140option in ``breakpoint`` completes to source files, the ``--shlib <path>`` option141to currently loaded shared libraries, etc. You can even do things like if you142specify ``--shlib <path>``, and are completing on ``--file <path>``, LLDB will only143list source files in the shared library specified by ``--shlib <path>``.144 145The individual commands are pretty extensively documented. You can use the ``help``146command to get an overview of which commands are available or to obtain details147about specific commands. There is also an ``apropos`` command that will search the148help text for all commands for a particular word and dump a summary help string149for each matching command.150 151Finally, there is a mechanism to construct aliases for commonly used commands.152For instance, if you get annoyed typing:153 154::155 156 (lldb) breakpoint set --file foo.c --line 12157 158You can do:159 160::161 162 (lldb) command alias bfl breakpoint set -f %1 -l %2163 (lldb) bfl foo.c 12164 165LLDB has a few aliases for commonly used commands (e.g. ``step``, ``next`` and166``continue``) but it does not try to be exhaustive because in our experience it167is more convenient to make the basic commands unique down to a letter or two,168and then learn these sequences than to fill the namespace with lots of aliases,169and then have to type them all the way out.170 171If the alias abbreviation or the full alias command collides with another172existing command, the command resolver will prefer to use the alias over any173other command as far as there is only one alias command match.174 175However, users are free to customize LLDB's command set however they like, and176since LLDB reads the file ``~/.lldbinit`` at startup, you can store all your177aliases there and they will be generally available to you. Your aliases are178also documented in the ``help`` command so you can remind yourself of what you have179set up.180 181One alias of note that LLDB does include by popular demand is a weak emulator of182GDB's ``break`` command. It does not try to do everything that GDB's break command183does (for instance, it does not handle ``foo.c::bar``). But it mostly works, and184makes the transition easier. Also, by popular demand, it is aliased to ``b``. If you185actually want to learn the LLDB command set natively, that means it will get in186the way of the rest of the breakpoint commands. Fortunately, if you do not like187one of our aliases, you can easily get rid of it by running, for example:188 189::190 191 (lldb) command unalias b192 193You can also do:194 195::196 197 (lldb) command alias b breakpoint198 199So you can run the native LLDB breakpoint command with just ``b``.200 201The LLDB command parser also supports "raw" commands, where, after command202options are stripped off, the rest of the command string is passed203uninterpreted to the command. This is convenient for commands whose arguments204might be some complex expression that would be painful to backslash protect.205For instance, the ``expression`` command is a "raw" command for obvious reasons.206The ``help`` output for a command will tell you if it is "raw" or not, so you207know what to expect. The one thing you have to watch out for is that since raw208commands still can have options, if your command string has dashes in it,209you will have to indicate these are not option markers by putting ``--`` after the210command name, but before your command string.211 212LLDB also has a built-in Python interpreter, which is accessible by the213``script`` command. All the functionality of the debugger is available as classes214in the Python interpreter, so the more complex commands that in GDB you would215introduce with the ``define`` command can be done by writing Python functions216using the LLDB Python library, then loading the scripts into your running217session and accessing them with the ``script`` command.218 219Loading a Program Into LLDB220---------------------------221 222First you need to set the program to debug. As with GDB, you can start LLDB and223specify the file you wish to debug on the command line:224 225::226 227 $ lldb /Projects/Sketch/build/Debug/Sketch.app228 Current executable set to '/Projects/Sketch/build/Debug/Sketch.app' (x86_64).229 230Or you can specify it after the fact with the ``file`` command:231 232::233 234 $ lldb235 (lldb) file /Projects/Sketch/build/Debug/Sketch.app236 Current executable set to '/Projects/Sketch/build/Debug/Sketch.app' (x86_64).237 238Setting Breakpoints239-------------------240 241We have discussed how to set breakpoints above. You can use ``help breakpoint set``242to see all the options for breakpoint setting. For instance, you could do:243 244::245 246 (lldb) breakpoint set --selector alignLeftEdges:247 Breakpoint created: 1: name = 'alignLeftEdges:', locations = 1, resolved = 1248 249You can find out about the breakpoints you have set with:250 251::252 253 (lldb) breakpoint list254 Current breakpoints:255 1: name = 'alignLeftEdges:', locations = 1, resolved = 1256 1.1: where = Sketch`-[SKTGraphicView alignLeftEdges:] + 33 at /Projects/Sketch/SKTGraphicView.m:1405, address = 0x0000000100010d5b, resolved, hit count = 0257 258 259Note that setting a breakpoint creates a logical breakpoint, which could260resolve to one or more locations. For instance, break by selector would set a261breakpoint on all the methods that implement that selector in the classes in262your program. Similarly, a file and line breakpoint might result in multiple263locations if that file and line were inlined in different places in your code.264 265The logical breakpoint has an integer id, and its locations have an id within266their parent breakpoint (the two are joined by a ``.``, e.g. ``1.1`` in the example267above).268 269Also logical breakpoints remain live so that if another shared library were270to be loaded that had another implementation of the ``alignLeftEdges:`` selector,271the new location would be added to breakpoint ``1`` (e.g. a ``1.2`` breakpoint would272be set on the newly loaded selector).273 274The other piece of information in the breakpoint listing is whether the275breakpoint location was resolved or not. A location gets resolved when the file276address it corresponds to gets loaded into the program you are debugging. For277instance if you set a breakpoint in a shared library that then gets unloaded,278that breakpoint location will remain, but it will no longer be resolved.279 280One other thing to note for GDB users is that LLDB acts like GDB with:281 282::283 284 (gdb) set breakpoint pending on285 286Which means that LLDB will always make a breakpoint from your specification, even if it287could not find any locations that match the specification. You can tell whether288the expression was resolved or not by checking the locations field in289``breakpoint list``, and LLDB reports the breakpoint as ``pending`` when you set it so290you can tell you have made a typo more easily, if that was indeed the reason no291locations were found:292 293::294 295 (lldb) breakpoint set --file foo.c --line 12296 Breakpoint created: 2: file ='foo.c', line = 12, locations = 0 (pending)297 WARNING: Unable to resolve breakpoint to any actual locations.298 299You can delete, disable, set conditions and ignore counts either on all the300locations generated by your logical breakpoint, or on any one of the particular301locations your specification resolved to. For instance, if you wanted to add a302command to print a backtrace when you hit this breakpoint you could do:303 304::305 306 (lldb) breakpoint command add 1.1307 Enter your debugger command(s). Type 'DONE' to end.308 > bt309 > DONE310 311By default, the breakpoint command add command takes LLDB command line312commands. You can also specify this explicitly by passing the ``--command``313option. Use ``--script`` if you want to implement your breakpoint command using314the Python script instead.315 316This is a convenient point to bring up another feature of the LLDB command317``help``. Do:318 319::320 321 (lldb) help break command add322 Add a set of commands to a breakpoint, to be executed whenever the breakpoint is hit.323 324 Syntax: breakpoint command add <cmd-options> <breakpt-id>325 etc...326 327When you see arguments to commands specified in the ``Syntax`` section in angle brackets328like ``<breakpt-id>``, that indicates that that is some common argument type that329you can get further help on from the command system. So in this case you could330do:331 332::333 334 (lldb) help <breakpt-id>335 <breakpt-id> -- Breakpoint ID's consist major and minor numbers; the major etc...336 337Breakpoint Names338----------------339 340Breakpoints carry two orthogonal sets of information: one specifies where to set341the breakpoint, and the other how to react when the breakpoint is hit. The latter342set of information (e.g. commands, conditions, hit-count, auto-continue...) we343call breakpoint options.344 345It is fairly common to want to apply one set of options to a number of breakpoints.346For instance, you might want to check that ``self == nil`` and if it is, print a347backtrace and continue, on a number of methods. One convenient way to do that would348be to make all the breakpoints, then configure the options with:349 350::351 352 (lldb) breakpoint modify -c "self == nil" -C bt --auto-continue 1 2 3353 354That is not too bad, but you have to repeat this for every new breakpoint you make,355and if you wanted to change the options, you have to remember all the ones you are356using this way.357 358Breakpoint names provide a convenient solution to this problem. The simple solution359would be to use the name to gather the breakpoints you want to affect this way into360a group. So when you make the breakpoint you would do:361 362::363 364 (lldb) breakpoint set -N SelfNil365 366Then when you have made all your breakpoints, you can set up or modify the options367using the name to collect all the relevant breakpoints.368 369::370 371 (lldb) breakpoint modify -c "self == nil" -C bt --auto-continue SelfNil372 373That is better, but suffers from the problem that when new breakpoints get374added, they do not pick up these modifications, and the options only exist in375the context of actual breakpoints, so they are hard to store and reuse.376 377An even better solution is to make a fully configured breakpoint name:378 379::380 381 (lldb) breakpoint name configure -c "self == nil" -C bt --auto-continue SelfNil382 383Then you can apply the name to your breakpoints, and they will all pick up384these options. The connection from name to breakpoints remains live, so when385you change the options configured on the name, all the breakpoints pick up386those changes. This makes it easy to use configured names to experiment with387your options.388 389You can make breakpoint names in your ``.lldbinit`` file, so you can use them to390can behaviors that you have found useful and reapply them in future sessions.391 392You can also make a breakpoint name from the options set on a breakpoint:393 394::395 396 (lldb) breakpoint name configure -B 1 SelfNil397 398which makes it easy to copy behavior from one breakpoint to a set of others.399 400Setting Watchpoints401-------------------402 403In addition to breakpoints, you can use help watchpoint to see all the commands404for watchpoint manipulations. For instance, you might do the following to watch405a variable called ``global`` for write operation, but only stop if the condition406``(global==5)`` is true:407 408::409 410 (lldb) watch set var global411 Watchpoint created: Watchpoint 1: addr = 0x100001018 size = 4 state = enabled type = w412 declare @ '/Volumes/data/lldb/svn/ToT/test/functionalities/watchpoint/watchpoint_commands/condition/main.cpp:12'413 (lldb) watch modify -c '(global==5)'414 (lldb) watch list415 Current watchpoints:416 Watchpoint 1: addr = 0x100001018 size = 4 state = enabled type = w417 declare @ '/Volumes/data/lldb/svn/ToT/test/functionalities/watchpoint/watchpoint_commands/condition/main.cpp:12'418 condition = '(global==5)'419 (lldb) c420 Process 15562 resuming421 (lldb) about to write to 'global'...422 Process 15562 stopped and was programmatically restarted.423 Process 15562 stopped and was programmatically restarted.424 Process 15562 stopped and was programmatically restarted.425 Process 15562 stopped and was programmatically restarted.426 Process 15562 stopped427 * thread #1: tid = 0x1c03, 0x0000000100000ef5 a.out`modify + 21 at main.cpp:16, stop reason = watchpoint 1428 frame #0: 0x0000000100000ef5 a.out`modify + 21 at main.cpp:16429 13430 14 static void modify(int32_t &var) {431 15 ++var;432 -> 16 }433 17434 18 int main(int argc, char** argv) {435 19 int local = 0;436 (lldb) bt437 * thread #1: tid = 0x1c03, 0x0000000100000ef5 a.out`modify + 21 at main.cpp:16, stop reason = watchpoint 1438 frame #0: 0x0000000100000ef5 a.out`modify + 21 at main.cpp:16439 frame #1: 0x0000000100000eac a.out`main + 108 at main.cpp:25440 frame #2: 0x00007fff8ac9c7e1 libdyld.dylib`start + 1441 (lldb) frame var global442 (int32_t) global = 5443 (lldb) watch list -v444 Current watchpoints:445 Watchpoint 1: addr = 0x100001018 size = 4 state = enabled type = w446 declare @ '/Volumes/data/lldb/svn/ToT/test/functionalities/watchpoint/watchpoint_commands/condition/main.cpp:12'447 condition = '(global==5)'448 hit_count = 5 ignore_count = 0449 (lldb)450 451Starting or Attaching to Your Program452-------------------------------------453 454To launch a program in LLDB you will use the ``process launch`` command or one of455its built in aliases:456 457::458 459 (lldb) process launch460 (lldb) run461 (lldb) r462 463You can also attach to a process by process ID or process name. When attaching464to a process by name, LLDB also supports the ``--waitfor`` option which waits for465the next process that has that name to show up, and attaches to it466 467::468 469 (lldb) process attach --pid 123470 (lldb) process attach --name Sketch471 (lldb) process attach --name Sketch --waitfor472 473After you launch or attach to a process, your process might stop somewhere:474 475::476 477 (lldb) process attach -p 12345478 Process 46915 Attaching479 Process 46915 Stopped480 1 of 3 threads stopped with reasons:481 * thread #1: tid = 0x2c03, 0x00007fff85cac76a, where = libSystem.B.dylib`__getdirentries64 + 10, stop reason = signal = SIGSTOP, queue = com.apple.main-thread482 483Note the line that says ``1 of 3 threads stopped with reasons:`` and the lines484that follow it. In a multi-threaded environment it is very common for more than485one thread to hit your breakpoint(s) before the kernel actually returns control486to the debugger. In that case, you will see all the threads that stopped for487some interesting reason listed in the stop message.488 489Controlling Your Program490------------------------491 492After launching, you can continue until you hit your breakpoint. The primitive commands493for process control all exist under the "thread" command:494 495::496 497 (lldb) thread continue498 Resuming thread 0x2c03 in process 46915499 Resuming process 46915500 (lldb)501 502At present you can only operate on one thread at a time, but the design will503ultimately support saying "step over the function in Thread 1, and step into the504function in Thread 2, and continue Thread 3" etc. When LLDB eventually supports505keeping some threads running while others are stopped this will be particularly506important. For convenience, however, all the stepping commands have easy aliases.507So ``thread continue`` is just ``c``, etc.508 509The other program stepping commands are pretty much the same as in GDB. You have got:510 511::512 513 (lldb) thread step-in // The same as GDB's "step" or "s"514 (lldb) thread step-over // The same as GDB's "next" or "n"515 (lldb) thread step-out // The same as GDB's "finish" or "f"516 517By default, LLDB does defined aliases to all common GDB process control commands518(``s``, ``step``, ``n``, ``next``, ``finish``). If LLDB is missing any, please add519them to your ``~/.lldbinit`` file using the ``command alias`` command.520 521LLDB also supports the step by instruction versions:522 523::524 525 526 (lldb) thread step-inst // The same as GDB's "stepi" / "si"527 (lldb) thread step-over-inst // The same as GDB's "nexti" / "ni"528 529Finally, LLDB has a run until line or frame exit stepping mode:530 531::532 533 (lldb) thread until 100534 535This command will run the thread in the current frame until it reaches line 100536in this frame or stops if it leaves the current frame. This is a pretty close537equivalent to GDB's ``until`` command.538 539One other useful thing to note about the lldb stepping commands is that they540are implemented as a stack of interruptible operations. Until the operation -541e.g. step to the next line - is completed, it will remain on the542stack. If the step over is interrupted and control returned to you,543any new stepping commands you issue won't replace the step-over, but instead544their operations will be pushed onto the stack after the original step over.545Then each of them will be retired as they are completed, finally returning to the546original step over operation.547 548Suppose, for instance, you ``step-over`` a source line with a function call.549If there is a breakpoint in that function, hitting the breakpoint will interrupt550the step over. At that point, you will likely want to examine the state at551the breakpoint, maybe stepping around in that frame, or stepping into other552functions, running some expressions, etc.553 554Because the original step-over has remained on the stack, when you've finished555your examinations, a simple ``continue`` will resume the original ``step-over``556operation, and you will arrive at the end of your starting source line in the557original frame.558 559This saves you from having to keep track of your original intention, and manually560issuing the requisite number of ``step-out`` commands to get back to the frame561you were stepping over. The stack maintains that information for you.562 563Hand-called functions using the ``expr`` command are also implemented by564operations on this same stack. So if you are calling some code with the ``expr`` command,565and hit a breakpoint during the evaluation of that code, you can examine566the state where you stopped, and when you're satisfied, issue a567``continue`` to finish the expression evaluation operation and print the function568result.569 570You can examine the state of the operations stack using the ``thread plan list``571command, and if, for instance, you decide you don't actually want that outermost572next to continue running, you can remove it with the ``thread plan discard``573command. If you are interested in following this process in more detail, the574``lldb step`` logging channel is useful source of information.575 576A process, by default, will share the LLDB terminal with the inferior process.577When in this mode, much like when debugging with GDB, when the process is578running anything you type will go to the ``STDIN`` of the inferior process. To579interrupt your inferior program, type ``CTRL+C``.580 581If you attach to a process, or launch a process with the ``--no-stdin`` option,582the command interpreter is always available to enter commands. It might be a583little disconcerting to GDB users to always have an ``(lldb)`` prompt. This allows584you to set a breakpoint, or use any other command without having to explicitly585interrupt the program you are debugging:586 587::588 589 (lldb) process continue590 (lldb) breakpoint set --name stop_here591 592There are many commands that won't work while running, and the command593interpreter will let you know when this is the case. Please file an issue if594it does not. This way of operation will set us up for a future debugging595mode called thread centric debugging. This mode will allow us to run all596threads and only stop the threads that are at breakpoints or have exceptions or597signals.598 599The commands that currently work while running include interrupting the process600to halt execution (``process interrupt``), getting the process status (``process status``),601breakpoint setting and clearing (``breakpoint [set|clear|enable|disable|list] ...``),602and memory reading and writing (``memory [read|write] ...``).603 604The question of disabling stdio when running brings up a good opportunity to605show how to set debugger properties. If you always want to run in606the ``--no-stdin`` mode, you can set this as a generic process property using the607LLDB ``settings`` command, which is equivalent to GDB's ``set`` command.608In this case you would say:609 610::611 612 (lldb) settings set target.process.disable-stdio true613 614Over time, GDB's ``set`` command became a wilderness of disordered options, so615that there were useful options that even experienced GDB users did not know616about because they were too hard to find. LLDB instead organizes the settings617hierarchically using the structure of the basic entities in the debugger. For618the most part anywhere you can specify a setting on a generic entity (threads,619for example) you can also apply the option to a particular instance. You can620view the available settings with the command ``settings list`` and there is help621on the settings command explaining how it works more generally.622 623Examining Thread State624----------------------625 626Once you have stopped, LLDB will choose a current thread, usually the one that627stopped "for a reason", and a current frame in that thread (on stop this is628always the bottom-most frame). Many the commands for inspecting state work on629this current thread/frame.630 631To inspect the current state of your process, you can start with the threads:632 633::634 635 (lldb) thread list636 Process 46915 state is Stopped637 * thread #1: tid = 0x2c03, 0x00007fff85cac76a, where = libSystem.B.dylib`__getdirentries64 + 10, stop reason = signal = SIGSTOP, queue = com.apple.main-thread638 thread #2: tid = 0x2e03, 0x00007fff85cbb08a, where = libSystem.B.dylib`kevent + 10, queue = com.apple.libdispatch-manager639 thread #3: tid = 0x2f03, 0x00007fff85cbbeaa, where = libSystem.B.dylib`__workq_kernreturn + 10640 641The ``*`` indicates that Thread 1 is the current thread. To get a backtrace for642that thread, do:643 644::645 646 (lldb) thread backtrace647 thread #1: tid = 0x2c03, stop reason = breakpoint 1.1, queue = com.apple.main-thread648 frame #0: 0x0000000100010d5b, where = Sketch`-[SKTGraphicView alignLeftEdges:] + 33 at /Projects/Sketch/SKTGraphicView.m:1405649 frame #1: 0x00007fff8602d152, where = AppKit`-[NSApplication sendAction:to:from:] + 95650 frame #2: 0x00007fff860516be, where = AppKit`-[NSMenuItem _corePerformAction] + 365651 frame #3: 0x00007fff86051428, where = AppKit`-[NSCarbonMenuImpl performActionWithHighlightingForItemAtIndex:] + 121652 frame #4: 0x00007fff860370c1, where = AppKit`-[NSMenu performKeyEquivalent:] + 272653 frame #5: 0x00007fff86035e69, where = AppKit`-[NSApplication _handleKeyEquivalent:] + 559654 frame #6: 0x00007fff85f06aa1, where = AppKit`-[NSApplication sendEvent:] + 3630655 frame #7: 0x00007fff85e9d922, where = AppKit`-[NSApplication run] + 474656 frame #8: 0x00007fff85e965f8, where = AppKit`NSApplicationMain + 364657 frame #9: 0x0000000100015ae3, where = Sketch`main + 33 at /Projects/Sketch/SKTMain.m:11658 frame #10: 0x0000000100000f20, where = Sketch`start + 52659 660You can also provide a list of threads to backtrace, or the keyword ``all`` to see all threads:661 662::663 664 (lldb) thread backtrace all665 666You can select the current thread, which will be used by default in all the667commands in the next section, with the ``thread select`` command:668 669::670 671 (lldb) thread select 2672 673where the thread index is just the one shown in the ``thread list`` listing.674 675 676Examining Stack Frame State677---------------------------678 679The most convenient way to inspect a frame's arguments and local variables is680to use the ``frame variable`` command:681 682::683 684 (lldb) frame variable685 self = (SKTGraphicView *) 0x0000000100208b40686 _cmd = (struct objc_selector *) 0x000000010001bae1687 sender = (id) 0x00000001001264e0688 selection = (NSArray *) 0x00000001001264e0689 i = (NSUInteger) 0x00000001001264e0690 c = (NSUInteger) 0x00000001001253b0691 692As you see above, if you do not specify any variable names, all arguments and693locals will be shown. If you call ``frame variable`` passing in the names of694particular local variables, only those variables will be printed. For instance:695 696::697 698 (lldb) frame variable self699 (SKTGraphicView *) self = 0x0000000100208b40700 701You can also pass in a path to some sub-element of one of the available locals,702and that sub-element will be printed. For instance:703 704::705 706 (lldb) frame variable self.isa707 (struct objc_class *) self.isa = 0x0000000100023730708 709The ``frame variable`` command is not a full expression parser but it does710support a few simple operations like ``&``, ``*``, ``->``, ``[]`` (no711overloaded operators). The array brackets can be used on pointers to treat712pointers as arrays:713 714::715 716 (lldb) frame variable *self717 (SKTGraphicView *) self = 0x0000000100208b40718 (NSView) NSView = {719 (NSResponder) NSResponder = {720 ...721 722 (lldb) frame variable &self723 (SKTGraphicView **) &self = 0x0000000100304ab724 725 (lldb) frame variable argv[0]726 (char const *) argv[0] = 0x00007fff5fbffaf8 "/Projects/Sketch/build/Debug/Sketch.app/Contents/MacOS/Sketch"727 728The frame variable command will also perform "object printing" operations on729variables (currently LLDB only supports ObjC printing, using the object's730``description`` method. Turn this on by passing the ``-o`` flag to frame variable:731 732::733 734 (lldb) frame variable -o self (SKTGraphicView *) self = 0x0000000100208b40 <SKTGraphicView: 0x100208b40>735 You can select another frame to view with the "frame select" command736 737 (lldb) frame select 9738 frame #9: 0x0000000100015ae3, where = Sketch`function1 + 33 at /Projects/Sketch/SKTFunctions.m:11739 740You can also move up and down the stack by passing the ``--relative`` (``-r``) option.741We also have built-in aliases ``u`` and ``d`` which behave like their GDB equivalents.742