Few clarifications.

llvm-svn: 113661

lldb/docs/lldb-for-gdb-users.txt

@@ -7,11 +7,28 @@ gdb command set:
 First some details on lldb command structure to help orient you...
 
 Unlike gdb's command set, which is rather free-form, we tried to make
-the lldb command set fairly structured.  The commands are all of the
+the lldb command syntax fairly structured.  The commands are all of the
 form
 
 <noun> <verb> [-options [option-value]] [argument [argument...]]
 
+The command line parsing is done before command execution, so it is
+uniform across all the commands.  The command syntax is very simple,
+basically arguments, options and option values are all white-space
+separated.  If you need to put a backslash or double-quote character
+in an argument you back-slash it in the argument.  That makes the
+command syntax more regular, but it also means you may have to
+quote some arguments in lldb that you wouldn't in gdb.
+
+Options can be placed anywhere on the command line, but if the arguments
+begin with a "-" then you have to tell lldb that you're done with options
+using the "--" option.  So for instance, the "process launch" command takes
+the "-s" option to mean "stop the process at the first instruction".  It's 
+arguments are the arguments you are passing to the program.  So if you wanted
+to pass an argument that contained a "-" you would have to do:
+
+(lldb) process launch -- -program_arg value
+
 We also tried to reduce the number of special purpose argument
 parsers, which sometimes forces the user to be a little more explicit
 about stating their intentions.  The first instance you'll note of
@@ -53,14 +70,7 @@ also makes it easy to compose specifications, like:
 for all functions called foo in the shared library foo.dylib.  Suggestions
 on more interesting primitives of this sort are also very welcome.
 
-The next structural difference between lldb & gdb is that the command
-line is actually parsed by the command interpreter not the commands.
-That means the command syntax is more regular, but it also means you
-may have to quote some arguments in lldb that you wouldn't in gdb.
-But the command syntax is very simple, basically arguments, options
-and option values are all white-space separated.  If you need to put a
-backslash or double-quote character in an argument you back-slash it
-in the argument.  So for instance:
+So for instance:
 
 (lldb) breakpoint set -n "-[SKTGraphicView alignLeftEdges:]"
 
@@ -150,13 +160,35 @@ Current breakpoints:
 1: name = 'alignLeftEdges:', locations = 1, resolved = 1
   1.1: where = Sketch`-[SKTGraphicView alignLeftEdges:] + 33 at /Volumes/ThePlayground/Users/jingham/Projects/Sketch/SKTGraphicView.m:1405, address = 0x0000000100010d5b, resolved, hit count = 0 
 
-Note that each "logical" breakpoint can have multiple resolved
-"locations".  The logical breakpoint has an integer id, and it's
-locations have a an id within their parent breakpoint (the two are
-joined by a ".", e.g. 1.1 in the example above.)  Also the breakpoints
-remain "live" so that if another shared library were to be loaded that
-had another implementation of the "alignLeftEdges:" selector, and new
-location would be added to the breakpoint 1 for it.
+Note that each "logical" breakpoint can have multiple "locations".
+The logical breakpoint has an integer id, and it's locations have a an
+id within their parent breakpoint (the two are joined by a ".",
+e.g. 1.1 in the example above.)  
+
+Also the breakpoints remain "live" so that if another shared library
+were to be loaded that had another implementation of the
+"alignLeftEdges:" selector, and new location would be added to the
+breakpoint 1 for it.
+
+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 dylib 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 always make breakpoints 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 the breakpoint
+reporting, and we mark the breakpoint as "pending" so you can tell you've made
+a typo more easily, if that was indeed the reason no locations were found:
+
+(lldb) b s -f no_such_file.c -l 10000000
+Breakpoint created: 1: file ='no_such_file.c', line = 10000000, locations = 0 (pending)
 
 You can delete, disable, set conditions and ignore counts either on
 all the locations generated by your logical breakpoint.  So for