We've discussed how to set breakpoints above. You can use help breakpoint set to see all the options for breakpoint setting. For instance, we might do:
(lldb) breakpoint set --selector alignLeftEdges:
Breakpoint created: 1: name = 'alignLeftEdges:', locations = 1, resolved = 1 You can find out about the breakpoints you've set with:
(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
Note that setting a breakpoint creates a logical breakpoint, which could resolve to one or more locations. For instance, break by selector would set a breakpoint on all the methods that implement that selector in the classes in your program. Similarly, a file and line breakpoint might result in multiple locations if that file and line were inlined in different places in your code.
The logical breakpoint has an integer id, and it's locations have an id within their parent breakpoint (the two are joined by a ".", e.g. 1.1 in the example above.)
Also the logical breakpoints remain live so that if another shared library were to be loaded that had another implementation of the "alignLeftEdges:" selector, the new location would be added to breakpoint 1 (e.g. a "1.2" breakpoint would be set on the newly loaded selector).
The other piece of information in the breakpoint listing is whether the breakpoint location was resolved or not. A location gets resolved when the file address it corresponds to gets loaded into the program you are debugging. For instance if you set a breakpoint in a shared library that then gets unloaded, that breakpoint location will remain, but it will no longer be resolved.
One other thing to note for gdb users is that lldb acts like gdb with:
(gdb) set breakpoint pending on That is, lldb will always make a breakpoint from your specification, even if it couldn't find any locations that match the specification. You can tell whether the expression was resolved or not by checking the locations field in "breakpoint list", and we report the breakpoint as "pending" when you set it so you can tell you've made a typo more easily, if that was indeed the reason no locations were found:
(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. You can delete, disable, set conditions and ignore counts either on all the locations generated by your logical breakpoint, or on any one of the particular locations your specification resolved to. For instance if we wanted to add a command to print a backtrace when we hit this breakpoint we could do:
(lldb) breakpoint command add 1.1
Enter your debugger command(s). Type 'DONE' to end.
> bt
> DONE By default, the breakpoint command add command takes lldb command line commands. You can also specify this explicitly by passing the "--command" option. Use "--script" if you want to implement your breakpoint command using the Python script instead.
This is an convenient point to bring up another feature of the lldb command help. Do:
(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... When you see arguments to commands specified in the Syntax in angle brackets like <breakpt-id>, that indicates that that is some common argument type that you can get further help on from the command system. So in this case you could do:
(lldb) help <breakpt-id>
<breakpt-id> -- Breakpoint ID's consist major and minor numbers; the major
etc...