After launching, we can continue until we hit our breakpoint. The primitive commands for process control all exist under the "thread" command:
(lldb) thread continue
Resuming thread 0x2c03 in process 46915
Resuming process 46915
(lldb) At present you can only operate on one thread at a time, but the design will ultimately support saying "step over the function in Thread 1, and step into the function in Thread 2, and continue Thread 3" etc. When we eventually support keeping some threads running while others are stopped this will be particularly important. For convenience, however, all the stepping commands have easy aliases. So "thread continue" is just "c", etc.
The other program stepping commands are pretty much the same as in gdb. You've got:
(lldb) thread step-in    // The same as gdb's "step" or "s" 
(lldb) thread step-over  // The same as gdb's "next" or "n"
(lldb) thread step-out   // The same as gdb's "finish" or "f"
By default, lldb does defined aliases to all common gdb process control commands ("s", "step", "n", "next", "finish"). If we have missed any, please add them to your ~/.lldbinit file using the "command alias" command.
lldb also supported the step by instruction versions:
(lldb) thread step-inst       // The same as gdb's "stepi" / "si"
(lldb) thread step-over-inst  // The same as gdb's "nexti" / "ni"
Finally, lldb has a run until line or frame exit stepping mode:
(lldb) thread until 100 This command will run the thread in the current frame till it reaches line 100 in this frame or stops if it leaves the current frame. This is a pretty close equivalent to gdb's "until" command.
A process, by default, will shared the lldb terminal with the inferior process. When in this mode, much like when debugging with gdb, when the process is running anything you type will go to the STDIN of the inferior process. To interrupt your inferior program, type CTRL+C.
If you attach to a process, or launch a process with the "--no-stdin" option, the command interpreter is always available to enter commands. This might be a little disconcerting to gdb users when always have an (lldb) prompt. This allows you to set a breakpoint, etc without having to explicitly interrupt the program you are debugging:
(lldb) process continue
(lldb) breakpoint set --name stop_here There are many commands that won't work while running, and the command interpreter should do a good job of letting you know when this is the case. If you find any instances where the command interpreter isn't doing its job, please file a bug. This way of operation will set us up for a future debugging mode called thread centric debugging. This mode will allow us to run all threads and only stop the threads that are at breakpoints or have exceptions or signals.
The commands that currently work while running include interrupting the process to halt execution ("process interrupt"), getting the process status ("process status"), breakpoint setting and clearing (" breakpoint [set|clear|enable|disable|list] ..."), and memory reading and writing (" memory [read|write] ...").
The question of disabling stdio when running brings up a good opportunity to show how to set debugger properties in general. If you always want to run in the --no-stdin mode, you can set this as a generic process property using the lldb "settings&qout; command, which is equivalent to gdb's "set" command. For instance, in this case you would say:
(lldb) settings set target.process.disable-stdio true Over time, gdb's "set command became a wilderness of disordered options, so that there were useful options that even experienced gdb users didn't know about because they were too hard to find. We tried to organize the settings hierarchically using the structure of the basic entities in the debugger. For the most part anywhere you can specify a setting on a generic entity (threads, for example) you can also apply the option to a particular instance, which can also be convenient at times. You can view the available settings with "settings list" and there is help on the settings command explaining how it works more generally.