[Lldb-commits] [lldb] r113674 - /lldb/trunk/docs/lldb-for-gdb-users.txt

Fri Sep 10 17:37:21 PDT 2010

Author: jmolenda
Date: Fri Sep 10 19:37:21 2010
New Revision: 113674

URL: http://llvm.org/viewvc/llvm-project?rev=113674&view=rev
Log:
Minor copy edits.

Modified:
    lldb/trunk/docs/lldb-for-gdb-users.txt

Modified: lldb/trunk/docs/lldb-for-gdb-users.txt
URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/docs/lldb-for-gdb-users.txt?rev=113674&r1=113673&r2=113674&view=diff
==============================================================================

--- lldb/trunk/docs/lldb-for-gdb-users.txt (original)
+++ lldb/trunk/docs/lldb-for-gdb-users.txt Fri Sep 10 19:37:21 2010
@@ -50,7 +50,8 @@
 
 (lldb) breakpoint set -f foo.c -l 12
 
-to set a file & line breakpoint.  To set a breakpoint on a function by name, you do:
+to set a file & line breakpoint.  To set a breakpoint on a function
+by name, you do:
 
 (lldb) breakpoint set -n foo
 
@@ -58,7 +59,7 @@
 
 (lldb) breakpoint set -M foo
 
-to break on all methods named foo, or:
+to break on all C++ methods named foo, or:
 
 (lldb) breakpoint set -S alignLeftEdges:
 
@@ -82,14 +83,14 @@
 
 lldb also supports command completion for source file names, symbol
 names, file names, etc. Completion is initiated by a hitting a <TAB>.
-Individual options a command can have different completers, so for
+Individual options in a command can have different completers, so for
 instance the -f option in "breakpoint" completes to source files, the
--s option to currently loaded dylibs, etc...  We can even do things
-like if you specify -s, and are completing on -f, we will only
-list source files in the dylib specified by -s...
+-s option to currently loaded shared libraries, etc...  We can even do 
+things like if you specify -s, and are completing on -f, we will only
+list source files in the shared library specified by -s...
 
 The individual commands are pretty extensively documented, using
-with the "help" command.  And there is an "apropos" command that will
+the "help" command.  And there is an "apropos" command that will
 search the help for a particular word and dump a summary help string
 for each matching command.
 
@@ -158,51 +159,53 @@
 (lldb) break list
 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 
+  1.1: where = Sketch`-[SKTGraphicView alignLeftEdges:] + 33 at /Projects/Sketch/SKTGraphicView.m:1405, address = 0x0000000100010d5b, resolved, hit count = 0 
 
 Note that each "logical" breakpoint can have multiple "locations".
-The logical breakpoint has an integer id, and it's locations have a an
+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 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.
+"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 dylib that then 
-gets unloaded, that breakpoint location will remain, but it will no longer
-be "resolved".
+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 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:
+That is, lldb should 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) 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
-instance if we wanted to add a command to print a backtrace when we
-hit this breakpoint we could do:
+You can delete, disable, set conditions and ignore counts either on all the
+locations generated by your logical breakpoint, or on 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) b command add -c 1.1
 Enter your debugger command(s).  Type 'DONE' to end.
 > bt
 > DONE
 
-The "-c" specifies that the breakpoint command is a set of lldb
+The "-c" option specifies that the breakpoint command is a set of lldb
 commmand interpreter commands.  Use "-s" if you want to implement your
-breakpoint command using the lldb Python interface instead.
+breakpoint command using the Python interface instead.
 
 
 c) Running the program:
@@ -240,7 +243,7 @@
 d) Controlling execution:
 
 
-Then we can continue till we hit our breakpoint.  The primitive
+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
@@ -250,31 +253,23 @@
 
 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
+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 type commands have easy
-aliases.  So "thread continue" is just "c", etc.
+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:
+The other program stepping commands are pretty much the same as in gdb.  
+You've got:
 
-(lldb) thread step-in
+  1. (lldb) thread step-in
+     The same as gdb's "step" -- there is also the alias "s" in lldb
 
-which is the same as gdb's "step" or the alias:
+  2. (lldb) thread step-over
+     The same as gdb's "next" -- there is also the alias "n" in lldb
 
-(lldb) s
-
-(lldb) thread step-over
-
-which is the same as gdb's "next" and is aliased to 
-
-(lldb) n
-
-(lldb) thread step-out
-
-which is the same as gdb's "finish" and is aliased to
-
-(lldb) f
+  3. (lldb) thread step-out
+     The same as gdb's "finish" -- there is also the alias "f" in lldb
 
 And the "by instruction" versions:
 
@@ -287,17 +282,16 @@
 
 which runs 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.
+close equivalent to gdb's "until" command.
 
 
-One thing here that might be a little disconcerting to gdb users here
-is that when you resume you immediately get a prompt back.  That's
-because the lldb interpreter remains live when you are running the
-target.  This allows you to set a breakpoint, etc without having to
-explicitly interrupt the program you are debugging.  We're still
-working out all the operations that it is safe to do while running.
-But this way of operation will set us up for "no stop" debugging when
-we get to implementing that.  
+One thing here that might be a little disconcerting to gdb users here is that
+when you resume process execution, you immediately get a prompt back.  That's
+because the lldb interpreter remains live when you are running the target.
+This allows you to set a breakpoint, etc without having to explicitly interrupt
+the program you are debugging.  We're still working out all the operations
+that it is safe to do while running.  But this way of operation will set us
+up for "no stop" debugging when we get to implementing that.
 
 If you want to interrupt a running program do:
 
@@ -353,7 +347,7 @@
 You can also provide a list of threads to backtrace, or the keyword
 "all" to see all threads:
 
-(lldb) thread backtrace all...
+(lldb) thread backtrace all
 
 Next task is inspecting data:
 
@@ -372,7 +366,8 @@
 (lldb) frame variable self
 (SKTGraphicView *) self = 0x0000000100208b40
 
-The frame variable command is not a full expression parser but it does support some common operations like defererencing:
+The frame variable command is not a full expression parser but it
+does support some common operations like defererencing:
 
 (lldb) fr v *self
 (SKTGraphicView *) self = 0x0000000100208b40
@@ -382,11 +377,11 @@
 
 and structure element references:
 
-(lldb) frame variable self.NS(lldb) frame variable self.isa
+(lldb) frame variable self.isa
 (struct objc_class *) self.isa = 0x0000000100023730
 
-The frame variable command will also perform "object printing" operations on variables (currently we
-only support NSPrintForDebugger) with:
+The frame variable command will also perform "object printing" operations on
+variables (currently we only support NSPrintForDebugger) with:
 
 (lldb) fr v -o self
 (SKTGraphicView *) self = 0x0000000100208b40
@@ -426,12 +421,13 @@
 $2 = (int) 22
 I have a pointer 0x0.
 
-One thing to note from this example is that lldb commands can be
-defined to take "raw" input.  "expression" is one of these.  So in the expression command,
-you don't have to quote your whole expression, nor backslash protect quotes, etc...
+One thing to note from this example is that lldb commands can be defined to
+take "raw" input.  "expression" is one of these.  So in the expression command,
+you don't have to quote your whole expression, nor backslash protect quotes,
+etc...
 
-Finally, the results of the expressions are stored in persistent
-variables (of the form \$([0-9])+) that you can use in further expressions, like:
+Finally, the results of the expressions are stored in persistent variables
+(of the form $[0-9]+) that you can use in further expressions, like:
 
 (lldb) expr self = $0
 $4 = (SKTGraphicView *) 0x0000000100135430



