tutorial.html revision 48e8dde874a0534690269ae4298c0c4f6debd024
1<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> 2<html xmlns="http://www.w3.org/1999/xhtml"> 3<head> 4<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" /> 5<link href="style.css" rel="stylesheet" type="text/css" /> 6<title>LLDB Tutorial</title> 7</head> 8 9<body> 10 <div class="www_title"> 11 The <strong>LLDB</strong> Debugger 12 </div> 13 14<div id="container"> 15 <div id="content"> 16 <!--#include virtual="sidebar.incl"--> 17 <div id="middle"> 18 <div class="post"> 19 <h1 class ="postheader">Getting Started</h1> 20 <div class="postcontent"> 21 22 <p>Here's a short precis of how to run lldb if you are familiar with the gdb command set. 23 We will start with some details on lldb command structure and syntax to help orient you.</p> 24 25 </div> 26 <div class="postfooter"></div> 27 28 <div class="post"> 29 <h1 class ="postheader">Command Structure</h1> 30 <div class="postcontent"> 31 32 <p>Unlike gdb's command set, which is rather free-form, we tried to make 33 the lldb command syntax fairly structured. The commands are all of the 34 form:</p> 35 36 <code color=#ff0000> 37 <noun> <verb> [-options [option-value]] [argument [argument...]] 38 </code> 39 40 <p>The command line parsing is done before command execution, so it is 41 uniform across all the commands. The command syntax for basic commands is very simple, 42 arguments, options and option values are all white-space 43 separated, and double-quotes are used to protect white-spaces in an argument. 44 If you need to put a backslash or double-quote character 45 in an argument you back-slash it in the argument. That makes the 46 command syntax more regular, but it also means you may have to 47 quote some arguments in lldb that you wouldn't in gdb.</p> 48 49 <p>Options can be placed anywhere on the command line, but if the arguments 50 begin with a "<code>-</code>" then you have to tell lldb that you're done with options 51 for the current command by adding an option termination: "<code>--</code>" 52 So for instance if you want to launch a process and give the "process launch" command 53 the "<code>--stop-at-entry</code>" option, yet you want the 54 process you are about to launch to be launched with the arguments 55 "<code>-program_arg value</code>", you would type:</p> 56 57 <code> 58 (lldb) process launch --stop-at-entry -- -program_arg value 59 </code> 60 61 <p>We also tried to reduce the number of special purpose argument 62 parsers, which sometimes forces the user to be a little more explicit 63 about stating their intentions. The first instance you'll note of 64 this is the breakpoint command. In gdb, to set a breakpoint, you 65 might enter</p> 66 67 <code> 68 (gdb) break foo.c:12 69 </code> 70 <p>to break at line 12 of foo.c, and:</p> 71 <code> 72 (gdb) break foo 73 </code> 74 75 <p>to break at the function <code>foo</code>. As time went on, the parser that tells <code>foo.c:12</code> 76 from <code>foo</code> from <code>foo.c::foo</code> (which means the function foo in the file 77 foo.c) got more and more complex and bizarre, and especially in C++ 78 there are times where there's really no way to specify the function 79 you want to break on. The lldb commands are more verbose but also more precise 80 and allow for intellegent auto completion. 81 82 <p>To set the same file and line breakpoint in LLDB you can enter either of:</p> 83 84 <code> 85 (lldb) breakpoint set --file foo.c --line 12 86 <br>(lldb) breakpoint set -f foo.c -l 12 87 </code> 88 89 <p>To set a breakpoint on a function named <code>foo</code> in LLDB you can enter either of:</p> 90 91 <code> 92 (lldb) breakpoint set --name foo 93 <br>(lldb) breakpoint set -n foo 94 </code> 95 96 <p>Setting breakpoints by name is even more specialized in LLDB as you can specify 97 that you want to set a breakpoint at a function by method name. To set a breakpoint 98 on all C++ methods named <code>foo</code> you can enter either of:</p> 99 100 <code> 101 (lldb) breakpoint set --method foo 102 <br>(lldb) breakpoint set -M foo 103 </code> 104 105 <p>To set a breakpoint Objective C selectors named <code>alignLeftEdges:</code> you can enter either of:</p> 106 107 <code> 108 (lldb) breakpoint set --selector alignLeftEdges: 109 <br>(lldb) breakpoint set -S alignLeftEdges: 110 </code> 111 112 <p>You can limit any breakpoints to a specific executable image by using 113 the "<code>--shlib <path></code>" ("<code>-s <path></code>" for short):</p> 114 115 <code> 116 (lldb) breakpoint set --shlib foo.dylib --name foo 117 <br>(lldb) breakpoint set -s foo.dylib -n foo 118 </code> 119 120 <p>Suggestions on more interesting primitives of this sort are also very welcome.</p> 121 122 <p>Just like gdb, the lldb command interpreter does a shortest unique 123 string match on command names, so the following two commands will 124 both execute the same command:</p> 125 126 <code> 127 (lldb) breakpoint set -n "-[SKTGraphicView alignLeftEdges:]" 128 <br>(lldb) br s -n "-[SKTGraphicView alignLeftEdges:]" 129 </code> 130 131 <p>lldb also supports command completion for source file names, symbol 132 names, file names, etc. Completion is initiated by a hitting a <b>TAB</b>. 133 Individual options in a command can have different completers, so for 134 instance the "<code>--file <path></code>" option in "breakpoint" completes to source files, the 135 "<code>--shlib <path></code>" option to currently loaded shared libraries, etc. We can even do 136 things like if you specify "<code>--shlib <path></code>", and are completing on "<code>--file <path></code>", we will only 137 list source files in the shared library specified by "<code>--shlib <path></code>".</p> 138 139 <p>The individual commands are pretty extensively documented, using 140 the <code>help</code> command. And there is an <code>apropos</code> command that will 141 search the help for a particular word and dump a summary help string 142 for each matching command.</p> 143 144 <p>Finally, there is a mechanism to construct aliases for commonly used 145 commands. So for instance if you get annoyed typing:</p> 146 147 <code> 148 (lldb) breakpoint set --file foo.c --line 12 149 </code> 150 151 <p>you can do:</p> 152 153 <code> 154 (lldb) command alias bfl breakpoint set -f %1 -l %2 155 <br>(lldb) bfl foo.c 12 156 </code> 157 158 <p>We have added a few aliases for commonly used commands (e.g. "step", 159 "next" and "continue") but we haven't tried to be exhaustive because 160 in our experience it is more convenient to make the basic commands 161 unique down to a letter or two, and then learn these sequences than 162 to fill the namespace with lots of aliases, and then have to type them 163 all the way out.</p> 164 165 <p>However, users are free to customize lldb's command set however they 166 like, and since lldb reads the file ~/.lldbinit at startup, you can 167 store all your aliases there and they will be generally available to 168 you. Your aliases are also documented in the help command so you can 169 remind yourself of what you've set up.</p> 170 171 <p> One alias of note that we do include by popular demand is a weak emulator 172 of gdb's "break" command. It doesn't try to do everything that gdb's 173 break command does (for instance, it doesn't handle <code>foo.c::bar</code>. But 174 it mostly works, and makes the transition easier. Also by popular demand, it 175 is aliased to <code>b</code>. If you actually want to learn the lldb command 176 set natively, that means it will get in the way of the rest of the breakpoint 177 commands. Fortunately, if you don't like one of our aliases, you an easily 178 get rid of it by running (for example):</p> 179 180 <code> 181 (lldb) command unalias b 182 </code> 183 184 <p>I actually also do:</p> 185 186 <code> 187 (lldb) command alias b breakpoint 188 </code> 189 190 <p>so I can run the native lldb breakpoint command with just <code>b</code></p> 191 192 <p>The lldb command parser also supports "raw" commands, where, after command options 193 are stripped off, the rest of the command string is passed uninterpreted to the command. 194 This is convenient for commands whose arguments might be some complex expression that would 195 be painful to backslash protect. 196 For instance the "expression" command is a "raw" command for obvious reasons. The 197 "help" output for a command will tell you if it is "raw" or not, so you know what to expect. 198 The one thing you have to watch out for is that since raw commands still can have options, 199 if your command string has dashes in it, you'll have to indicate these are not option 200 markers by putting "--" after the command name, but before your command string. 201 202 <p>lldb also has a built-in Python interpreter, which is accessible by 203 the "script" command. All the functionality of the debugger is 204 available as classes in the Python interpreter, so the more complex 205 commands that in gdb you would introduce with the "define" command can 206 be done by writing Python functions using the lldb-Python library, 207 then loading the scripts into your running session and accessing them 208 with the "script" command.</p> 209 210 <p>Having given an overview of lldb's command syntax, we proceed to lay out the stages 211 of a standard debug session.</p> 212 213 </div> 214 <div class="postfooter"></div> 215 216 217 <div class="post"> 218 <h1 class ="postheader">Loading a program into lldb</h1> 219 <div class="postcontent"> 220 221 <p>First we need to set the program to debug. As with gdb, you 222 can start lldb and specify the file you wish to debug on the command line:</p> 223 224 <code> 225 $ lldb /Projects/Sketch/build/Debug/Sketch.app 226 <br>Current executable set to '/Projects/Sketch/build/Debug/Sketch.app' (x86_64). 227 </code> 228 229 <p>or you can specify it after the fact with the "file" command:</p> 230 231 <code> 232 $ lldb 233 <br>(lldb) file /Projects/Sketch/build/Debug/Sketch.app 234 <br>Current executable set to '/Projects/Sketch/build/Debug/Sketch.app' (x86_64). 235 </code> 236 <p> 237 </div> 238 <div class="postfooter"></div> 239 240 <div class="post"> 241 <h1 class ="postheader">Setting breakpoints</h1> 242 <div class="postcontent"> 243 244 <p>We've discussed how to set breakpoints above. You can use <code>help breakpoint set</code> 245 to see all the options for breakpoint setting. For instance, we might do:</p> 246 247 <code> 248 (lldb) breakpoint set --selector alignLeftEdges: 249 <br>Breakpoint created: 1: name = 'alignLeftEdges:', locations = 1, resolved = 1 250 </code> 251 252 <p>You can find out about the breakpoints you've set with:</p> 253 254 <pre><tt>(lldb) breakpoint list 255Current breakpoints: 2561: name = 'alignLeftEdges:', locations = 1, resolved = 1 257 1.1: where = Sketch`-[SKTGraphicView alignLeftEdges:] + 33 at /Projects/Sketch/SKTGraphicView.m:1405, address = 0x0000000100010d5b, resolved, hit count = 0 258</tt></pre> 259 260 <p>Note that setting a breakpoint creates a <i>logical</i> breakpoint, which could 261 resolve to one or more <i>locations</i>. For instance, break by selector would 262 set a breakpoint on all the methods that implement that selector in the classes in 263 your program. Similarly, a file and line breakpoint might result in multiple 264 locations if that file and line were inlined in different places in your code.</p> 265 266 <p>The logical breakpoint has an integer id, and it's locations have an 267 id within their parent breakpoint (the two are joined by a ".", 268 e.g. 1.1 in the example above.) </p> 269 270 <p>Also the logical breakpoints remain <i>live</i> so that if another shared library 271 were to be loaded that had another implementation of the 272 "<code>alignLeftEdges:</code>" selector, the new location would be added to 273 breakpoint 1 (e.g. a "1.2" breakpoint would be set on the newly loaded 274 selector).</p> 275 276 <p>The other piece of information in the breakpoint listing is whether the 277 breakpoint location was <i>resolved</i> or not. A location gets resolved when 278 the file address it corresponds to gets loaded into the program you are 279 debugging. For instance if you set a breakpoint in a shared library that 280 then gets unloaded, that breakpoint location will remain, but it will no 281 longer be <i>resolved</i>.</p> 282 283 <p>One other thing to note for gdb users is that lldb acts like gdb with:</p> 284 285 <code> 286 (gdb) set breakpoint pending on 287 </code> 288 289 <p>That is, lldb will always make a breakpoint from your specification, even 290 if it couldn't find any locations that match the specification. You can tell 291 whether the expression was resolved or not by checking the locations field 292 in "breakpoint list", and we report the breakpoint as "pending" when you 293 set it so you can tell you've made a typo more easily, if that was indeed 294 the reason no locations were found:</p> 295 296 <code> 297 (lldb) breakpoint set --file foo.c --line 12 298 <br>Breakpoint created: 2: file ='foo.c', line = 12, locations = 0 (pending) 299 <br>WARNING: Unable to resolve breakpoint to any actual locations. 300 </code> 301 302 <p>You can delete, disable, set conditions and ignore counts either on all the 303 locations generated by your logical breakpoint, or on any one of the particular locations 304 your specification resolved to. For instance if we wanted to add a command 305 to print a backtrace when we hit this breakpoint we could do:</p> 306 307 <code> 308 (lldb) breakpoint command add 1.1 309 <br>Enter your debugger command(s). Type 'DONE' to end. 310 <br>> bt 311 <br>> DONE 312 </code> 313 314 <p>By default, the <code> breakpoint command add</code> command takes lldb command line commands. 315 You can also specify this explicitly by passing the "<code>--command</code>" option. 316 Use "<code>--script</code>" if you want to implement your breakpoint command using the Python script instead.</p> 317 318 <p>This is an convenient point to bring up another feature of the lldb command help. Do:</p> 319 320 <code> 321 (lldb) help break command add 322 <br>Add a set of commands to a breakpoint, to be executed whenever the breakpoint is hit. 323 <br> 324 <br>Syntax: breakpoint command add <cmd-options> <breakpt-id> 325 <br> etc... 326 </code> 327 328 <p>When you see arguments to commands specified in the Syntax in angle 329 brackets like <code><breakpt-id></code>, that indicates that 330 that is some common argument type that you can get further help on from the command system. 331 So in this case you could do:</p> 332 333 <code> 334 (lldb) help <breakpt-id> 335 <br><breakpt-id> -- Breakpoint ID's consist major and minor numbers; the major 336 <br> etc... 337 </code> 338 339 </div> 340 <div class="postfooter"></div> 341 342 <div class="post"> 343 <h1 class ="postheader">Setting watchpoints</h1> 344 <div class="postcontent"> 345 346 <p>In addition to breakpoints, you can use <code>help watchpoint</code> 347 to see all the commands for watchpoint manipulations. For instance, we might do the following to watch 348 a variable called 'global' for write operation, but only stop if the condition '(global==5)' is true:</p> 349 350 <pre><tt>(lldb) watch set var -w write global 351Watchpoint created: Watchpoint 1: addr = 0x100001018 size = 4 state = enabled type = w 352 declare @ '/Volumes/data/lldb/svn/ToT/test/functionalities/watchpoint/watchpoint_commands/condition/main.cpp:12' 353(lldb) watch modify -c '(global==5)' 354(lldb) watch list 355Current watchpoints: 356Watchpoint 1: addr = 0x100001018 size = 4 state = enabled type = w 357 declare @ '/Volumes/data/lldb/svn/ToT/test/functionalities/watchpoint/watchpoint_commands/condition/main.cpp:12' 358 condition = '(global==5)' 359(lldb) c 360Process 15562 resuming 361(lldb) about to write to 'global'... 362Process 15562 stopped and was programmatically restarted. 363Process 15562 stopped and was programmatically restarted. 364Process 15562 stopped and was programmatically restarted. 365Process 15562 stopped and was programmatically restarted. 366Process 15562 stopped 367* thread #1: tid = 0x1c03, 0x0000000100000ef5 a.out`modify + 21 at main.cpp:16, stop reason = watchpoint 1 368 frame #0: 0x0000000100000ef5 a.out`modify + 21 at main.cpp:16 369 13 370 14 static void modify(int32_t &var) { 371 15 ++var; 372-> 16 } 373 17 374 18 int main(int argc, char** argv) { 375 19 int local = 0; 376(lldb) bt 377* thread #1: tid = 0x1c03, 0x0000000100000ef5 a.out`modify + 21 at main.cpp:16, stop reason = watchpoint 1 378 frame #0: 0x0000000100000ef5 a.out`modify + 21 at main.cpp:16 379 frame #1: 0x0000000100000eac a.out`main + 108 at main.cpp:25 380 frame #2: 0x00007fff8ac9c7e1 libdyld.dylib`start + 1 381(lldb) frame var global 382(int32_t) global = 5 383(lldb) watch list -v 384Current watchpoints: 385Watchpoint 1: addr = 0x100001018 size = 4 state = enabled type = w 386 declare @ '/Volumes/data/lldb/svn/ToT/test/functionalities/watchpoint/watchpoint_commands/condition/main.cpp:12' 387 condition = '(global==5)' 388 hw_index = 0 hit_count = 5 ignore_count = 0 389(lldb) </tt></pre> 390 </div> 391 <div class="postfooter"></div> 392 393 <div class="post"> 394 <h1 class ="postheader">Starting or attaching to your Program</h1> 395 <div class="postcontent"> 396 397 <p>To launch a program in lldb we use the "<code>process launch</code>" command or 398 one of its built in aliases:</p> 399 400 <code> 401 (lldb) process launch 402 <br>(lldb) run 403 <br>(lldb) r 404 </code> 405 406 <p>You can also attach to a process by process ID or process name. 407 When attaching to a process by name, lldb also supports the "<code>--waitfor</code>" option which waits for the 408 next process that has that name to show up, and attaches to it</p> 409 410 <code> 411 (lldb) process attach --pid 123 412 <br>(lldb) process attach --name Sketch 413 <br>(lldb) process attach --name Sketch --waitfor 414 </code> 415 416 <p>After you launch or attach to a process, your process might stop 417 somewhere:</p> 418 <code> 419 (lldb) process attach -p 12345 420 <br>Process 46915 Attaching 421 <br>Process 46915 Stopped 422 <br>1 of 3 threads stopped with reasons: 423 <br>* thread #1: tid = 0x2c03, 0x00007fff85cac76a, where = libSystem.B.dylib`__getdirentries64 + 10, stop reason = signal = SIGSTOP, queue = com.apple.main-thread 424 </code> 425 426 427 <p>Note the line that says "<code>1 of 3 threads stopped with reasons:</code>" and the 428 lines that follow it. In a multi-threaded environment it is very 429 common for more than one thread to hit your breakpoint(s) before the 430 kernel actually returns control to the debugger. In that case, you 431 will see all the threads that stopped for some interesting reason 432 listed in the stop message.</p> 433 434 </div> 435 <div class="postfooter"></div> 436 437 <div class="post"> 438 <h1 class ="postheader">Controlling your Program</h1> 439 <div class="postcontent"> 440 441 442 <p>After launching, we can continue until we hit our breakpoint. The primitive 443 commands for process control all exist under the "thread" command:</p> 444 445 <code> 446 (lldb) thread continue 447 <br>Resuming thread 0x2c03 in process 46915 448 <br>Resuming process 46915 449 <br>(lldb) 450 </code> 451 452 <p>At present you can only operate on one thread at a time, but the 453 design will ultimately support saying "step over the function in 454 Thread 1, and step into the function in Thread 2, and continue Thread 455 3" etc. When we eventually support keeping some threads running while 456 others are stopped this will be particularly important. For 457 convenience, however, all the stepping commands have easy aliases. 458 So "thread continue" is just "c", etc.</p> 459 460 <p>The other program stepping commands are pretty much the same as in gdb. 461 You've got:</p> 462 463 <pre><tt>(lldb) thread step-in // The same as gdb's "step" or "s" 464(lldb) thread step-over // The same as gdb's "next" or "n" 465(lldb) thread step-out // The same as gdb's "finish" or "f" 466</tt></pre> 467 468 <p>By default, lldb does defined aliases to all common gdb process control 469 commands ("<code>s</code>", "<code>step</code>", "<code>n</code>", "<code>next</code>", "<code>finish</code>"). 470 If we have missed any, please add them to your <code>~/.lldbinit</code> file 471 using the "<code>command alias</code>" command. 472 473 <p>lldb also supported the <i>step by instruction</i> versions:</p> 474 <pre><tt>(lldb) thread step-inst // The same as gdb's "stepi" / "si" 475(lldb) thread step-over-inst // The same as gdb's "nexti" / "ni" 476</tt></pre> 477 478 <p>Finally, lldb has a <i>run until line or frame exit</i> stepping mode:</p> 479 480 <code> 481 (lldb) thread until 100 482 </code> 483 484 <p>This command will run the thread in the current frame till it reaches line 100 in 485 this frame or stops if it leaves the current frame. This is a pretty 486 close equivalent to gdb's "<code>until</code>" command.</p> 487 488 <p>A process, by default, will shared the lldb terminal with the inferior 489 process. When in this mode, much like when debugging with gdb, when 490 the process is running anything you type will go to the STDIN of the 491 inferior process. To interrupt your inferior program, type CTRL+C.</p> 492 493 <p>If you attach to a process, or launch a process with the "<code>--no-stdin</code>" 494 option, the command interpreter is always available to enter commands. This 495 might be a little disconcerting to gdb users when always have an <code>(lldb)</code> 496 prompt. This allows you to set a breakpoint, etc without having to explicitly interrupt 497 the program you are debugging:</p> 498 499 <code> 500 (lldb) process continue 501 <br>(lldb) breakpoint set --name stop_here 502 </code> 503 504 <p>There are many commands that won't work while running, and the command 505 interpreter should do a good job of letting you know when this is the 506 case. If you find any instances where the command interpreter isn't 507 doing its job, please file a bug. This way of operation will set us 508 up for a future debugging mode called <i>thread centric debugging</i>. 509 This mode will allow us to run all threads and only stop the threads 510 that are at breakpoints or have exceptions or signals.</p> 511 512 <p>The commands that currently work while running include 513 interrupting the process to halt execution ("<code>process interrupt</code>"), 514 getting the process status ("<code>process status</code>"), 515 breakpoint setting and clearing ("<code> breakpoint [set|clear|enable|disable|list] ...</code>"), 516 and memory reading and writing ("<code> memory [read|write] ...</code>"). 517 </p> 518 519 <p>The question of disabling stdio when running brings up a good opportunity to 520 show how to set debugger properties in general. 521 If you always want to run in the <code>--no-stdin</code> mode, you can set this 522 as a generic process property using the lldb "<code>settings</code>&qout; command, 523 which is equivalent to gdb's "<code>set</code>" command. For instance, 524 in this case you would say:</p> 525 526 <code> 527 (lldb) settings set target.process.disable-stdio true 528 </code> 529 530 <p>Over time, gdb's "<code>set</code> command became a wilderness of disordered options, 531 so that there were useful options that even experienced gdb users didn't know about 532 because they were too hard to find. We tried to organize the settings hierarchically 533 using the structure of the basic entities in the debugger. For the most part anywhere 534 you can specify a setting on a generic entity (threads, for example) you can also apply 535 the option to a particular instance, which can also be convenient at times. 536 You can view the available settings with "<code>settings list</code>" and 537 there is help on the settings command explaining how it works more generally.</p> 538 539 </div> 540 <div class="postfooter"></div> 541 542 <div class="post"> 543 <h1 class ="postheader">Examining Thread State</h1> 544 <div class="postcontent"> 545 546 <p>Once you've stopped, lldb will choose a current thread, usually the 547 one that stopped "for a reason", and a current frame in that thread (on stop this is always the bottom-most frame). 548 Many the commands for inspecting state work on this current 549 thread/frame.</p> 550 551 <p>To inspect the current state of your process, you can start with the 552 threads:</p> 553 554 <pre><tt>(lldb) thread list 555Process 46915 state is Stopped 556* thread #1: tid = 0x2c03, 0x00007fff85cac76a, where = libSystem.B.dylib`__getdirentries64 + 10, stop reason = signal = SIGSTOP, queue = com.apple.main-thread 557 thread #2: tid = 0x2e03, 0x00007fff85cbb08a, where = libSystem.B.dylib`kevent + 10, queue = com.apple.libdispatch-manager 558 thread #3: tid = 0x2f03, 0x00007fff85cbbeaa, where = libSystem.B.dylib`__workq_kernreturn + 10 559</tt></pre> 560 561 <p>The * indicates that Thread 1 is the current thread. To get a 562 backtrace for that thread, do:</p> 563 564 <pre><tt>(lldb) thread backtrace 565thread #1: tid = 0x2c03, stop reason = breakpoint 1.1, queue = com.apple.main-thread 566 frame #0: 0x0000000100010d5b, where = Sketch`-[SKTGraphicView alignLeftEdges:] + 33 at /Projects/Sketch/SKTGraphicView.m:1405 567 frame #1: 0x00007fff8602d152, where = AppKit`-[NSApplication sendAction:to:from:] + 95 568 frame #2: 0x00007fff860516be, where = AppKit`-[NSMenuItem _corePerformAction] + 365 569 frame #3: 0x00007fff86051428, where = AppKit`-[NSCarbonMenuImpl performActionWithHighlightingForItemAtIndex:] + 121 570 frame #4: 0x00007fff860370c1, where = AppKit`-[NSMenu performKeyEquivalent:] + 272 571 frame #5: 0x00007fff86035e69, where = AppKit`-[NSApplication _handleKeyEquivalent:] + 559 572 frame #6: 0x00007fff85f06aa1, where = AppKit`-[NSApplication sendEvent:] + 3630 573 frame #7: 0x00007fff85e9d922, where = AppKit`-[NSApplication run] + 474 574 frame #8: 0x00007fff85e965f8, where = AppKit`NSApplicationMain + 364 575 frame #9: 0x0000000100015ae3, where = Sketch`main + 33 at /Projects/Sketch/SKTMain.m:11 576 frame #10: 0x0000000100000f20, where = Sketch`start + 52 577</tt></pre> 578 579 <p>You can also provide a list of threads to backtrace, or the keyword 580 "all" to see all threads:</p> 581 582 <code> 583 (lldb) thread backtrace all 584 </code> 585 586 <p>You can select the current thread, which will be used by default in all the commands in 587 the next section, with the "thread select" command:</p> 588 589 <code> 590 (lldb) thread select 2 591 </code> 592 593 <p>where the thread index is just the one shown in the "<code>thread list</code>" listing. 594 595 </div> 596 <div class="postfooter"></div> 597 598 <div class="post"> 599 <h1 class ="postheader">Examining Stack Frame State</h1> 600 <div class="postcontent"> 601 602 603 <p>The most convenient way to inspect a frame's arguments and local variables is to use the "<code>frame variable</code>" command:</p> 604 605 <code> 606 (lldb) frame variable 607 <br>self = (SKTGraphicView *) 0x0000000100208b40 608 <br>_cmd = (struct objc_selector *) 0x000000010001bae1 609 <br>sender = (id) 0x00000001001264e0 610 <br>selection = (NSArray *) 0x00000001001264e0 611 <br>i = (NSUInteger) 0x00000001001264e0 612 <br>c = (NSUInteger) 0x00000001001253b0 613 </code> 614 615 <p>As you see above, if you don't specify any variable names, all arguments 616 and locals will be shown. If you call "<code>frame variable</code>" 617 passing in the names of a particular local(s), only those variables 618 will be printed. For instance: 619 </p> 620 621 <code> 622 (lldb) frame variable self 623 <br>(SKTGraphicView *) self = 0x0000000100208b40 624 </code> 625 626 <p>You can also pass in a path to some subelement of one of the available locals, 627 and that sub-element will be printed. For instance: 628 </p> 629 630 <code> 631 <br>(lldb) frame variable self.isa 632 <br>(struct objc_class *) self.isa = 0x0000000100023730 633 </code> 634 635 <p>The "<code>frame variable</code>" command is not a full expression 636 parser but it does support a few simple operations like &, *, ->, [] (no overloaded 637 operators). The array brackets can be used on pointers to treat pointers 638 as arrays:</p> 639 640 <code> 641 (lldb) frame variable *self 642 <br>(SKTGraphicView *) self = 0x0000000100208b40 643 <br>(NSView) NSView = { 644 <br>(NSResponder) NSResponder = { 645 <br>... 646 <br> 647 <br>(lldb) frame variable &self 648 <br>(SKTGraphicView **) &self = 0x0000000100304ab 649 <br> 650 <br>(lldb) frame variable argv[0] 651 <br>(char const *) argv[0] = 0x00007fff5fbffaf8 "/Projects/Sketch/build/Debug/Sketch.app/Contents/MacOS/Sketch" 652 </code> 653 654 <p>The frame variable command will also perform "object printing" operations on 655 variables (currently we only support ObjC printing, using the object's "description" method. 656 Turn this on by passing the -o flag to frame variable:</p> 657 658 <code> 659 (lldb) frame variable -o self 660 (SKTGraphicView *) self = 0x0000000100208b40 <SKTGraphicView: 0x100208b40> 661 </code> 662 663 <p>You can select another frame to view with the "<code>frame select</code>" command</p> 664 665 <code> 666 (lldb) frame select 9 667 <br>frame #9: 0x0000000100015ae3, where = Sketch`function1 + 33 at /Projects/Sketch/SKTFunctions.m:11 668 </code> 669 670 <p>You can also move up and down the stack by passing the "<code>--relative</code>" ("<code>-r</code>") 671 option. And we have built-in aliases "<code>u</code>" and "<code>d</code>" which 672 behave like their gdb equivalents. 673 674 <p>If you need to view more complex data or change program data, you can 675 use the general "expression" command. It takes an expression and 676 evaluates it in the scope of the currently selected frame. For instance:</p> 677 678 <code> 679 (lldb) expr self 680 <br>$0 = (SKTGraphicView *) 0x0000000100135430 681 <br>(lldb) expr self = 0x00 682 <br>$1 = (SKTGraphicView *) 0x0000000000000000 683 <br>(lldb) frame var self 684 <br>(SKTGraphicView *) self = 0x0000000000000000 685 </code> 686 687 <p>You can also call functions:</p> 688 689 <code> 690 (lldb) expr (int) printf ("I have a pointer 0x%llx.\n", self) 691 <br>$2 = (int) 22 692 <br>I have a pointer 0x0. 693 </code> 694 695 <p>As I said above, "expression" is one of the "raw" commands. So 696 you don't have to quote your whole expression, nor backslash protect quotes, 697 etc...</p> 698 699 <p>Finally, the results of the expressions are stored in persistent variables 700 (of the form $[0-9]+) that you can use in further expressions, like:</p> 701 702 <code> 703 (lldb) expr self = $0 704 <br>$4 = (SKTGraphicView *) 0x0000000100135430 705 </code> 706 <p> 707 </div> 708 <div class="postfooter"></div> 709 710 </div> 711 </div> 712 </div> 713</div> 714</body> 715</html> 716