Fix document typos, indentation in python code, and API examples.

Patch by Bruce Mitchener!

llvm-svn: 175002

diff --git a/lldb/docs/code-signing.txt b/lldb/docs/code-signing.txt
index f1ba328829324bc0449a3abdbb04156168ba4032..1c8220a50a263a7e16baeae22f0c5fa2cac91055 100644 (file)
--- a/lldb/docs/code-signing.txt
+++ b/lldb/docs/code-signing.txt
@@ -61,7 +61,7 @@ rm -f ~/Desktop/lldb_codesign.cer
   "login", but the one in "System"), and select "Delete" to delete it from
   the "System" keychain.
 - Reboot
-- Clean by removing all previously creating code signed binarires and rebuild
+- Clean by removing all previously creating code signed binaries and rebuild
   lldb and you should be able to debug.
 
 That should do it.

diff --git a/lldb/docs/lldb-for-gdb-users.txt b/lldb/docs/lldb-for-gdb-users.txt
index a45bc4386cb8fc40c4230cb3c61959fbde232146..79f34736a065eeb0e240bba26014d4501fd2550e 100644 (file)
--- a/lldb/docs/lldb-for-gdb-users.txt
+++ b/lldb/docs/lldb-for-gdb-users.txt
@@ -204,7 +204,7 @@ Enter your debugger command(s).  Type 'DONE' to end.
 > DONE
 
 The "-c" option specifies that the breakpoint command is a set of lldb
-commmand interpreter commands.  Use "-s" if you want to implement your
+command interpreter commands.  Use "-s" if you want to implement your
 breakpoint command using the Python interface instead.
 
 
@@ -434,7 +434,7 @@ $4 = (SKTGraphicView *) 0x0000000100135430
 
 f) Customization:
 
-You can use the embedded Python interprter to add the following 'pwd' and 'cd' commands
+You can use the embedded Python interpreter to add the following 'pwd' and 'cd' commands
 for your lldb session:
 
 (lldb) script import os

diff --git a/lldb/docs/lldb-gdb-remote.txt b/lldb/docs/lldb-gdb-remote.txt
index d4136440c1e067854c9f29b75087c69dd3fb252f..5aabb948dc4fc07aaf120ed42098c786d2afd67f 100644 (file)
--- a/lldb/docs/lldb-gdb-remote.txt
+++ b/lldb/docs/lldb-gdb-remote.txt
@@ -27,7 +27,7 @@ added above and beyond the standard GDB remote protocol packets.
 //  the performance of the connection.
 //----------------------------------------------------------------------
 Having to send an ACK/NACK after every packet slows things down a bit, so we
-have a way to disable ACK packets to mimize the traffic for reliable
+have a way to disable ACK packets to minimize the traffic for reliable
 communication interfaces (like sockets). Below GDB or LLDB will send this
 packet to try and disable ACKs. All lines that start with "send packet: " are
 from GDB/LLDB, and all lines that start with "read packet: " are from the GDB
@@ -336,7 +336,7 @@ format      The preferred format for display of this register. The value must
                 vector-float32
                 vector-uint128
 
-set         The regiter set name as a string that this register belongs to.
+set         The register set name as a string that this register belongs to.
 
 gcc         The GCC compiler registers number for this register (used for
             EH frame and other compiler information that is encoded in the
@@ -438,7 +438,7 @@ Key value pairs are one of:
 
 cputype: is a number that is the mach-o CPU type that is being debugged
 cpusubtype: is a number that is the mach-o CPU subtype type that is being debugged
-ostype: is a string the represents the OS being debugged (darwin, lunix, freebsd)
+ostype: is a string the represents the OS being debugged (darwin, linux, freebsd)
 vendor: is a string that represents the vendor (apple)
 endian: is one of "little", "big", or "pdp"
 ptrsize: is a number that represents how big pointers are in bytes on the debug target
@@ -454,7 +454,7 @@ ptrsize: is a number that represents how big pointers are in bytes on the debug
 //  the qHostInfo may not disambiguate sufficiently to know what kind of 
 //  process is being debugged.
 //  e.g. on a 64-bit x86 Mac system both 32-bit and 64-bit user processes are possible,
-//  and with Mach-O univeral files, the executable file may contain both 32- and 
+//  and with Mach-O universal files, the executable file may contain both 32- and 
 //  64-bit slices so it may be impossible to know until you're attached to a real
 //  process to know what you're working with.
 //
@@ -481,7 +481,7 @@ effective-uid: the effective user id of the process
 effective-gid: the effective group id of the process
 cputype: the Mach-O CPU type of the process
 cpusubtype: the Mach-O CPU subtype of the process
-ostype: is a string the represents the OS being debugged (darwin, lunix, freebsd)
+ostype: is a string the represents the OS being debugged (darwin, linux, freebsd)
 vendor: is a string that represents the vendor (apple)
 endian: is one of "little", "big", or "pdp"
 ptrsize: is a number that represents how big pointers are in bytes
@@ -507,8 +507,8 @@ ptrsize: is a number that represents how big pointers are in bytes
 
 LLDB and GDB both support the "qShlibInfoAddr" packet which is a hint to each
 debugger as to where to find the dynamic loader information. For darwin
-binaires that run in user land this is the address of the "all_image_infos"
-stucture in the "/usr/lib/dyld" executable, or the result of a TASK_DYLD_INFO
+binaries that run in user land this is the address of the "all_image_infos"
+structure in the "/usr/lib/dyld" executable, or the result of a TASK_DYLD_INFO
 call. The result is returned as big endian hex bytes that are the address
 value:
 
@@ -559,7 +559,7 @@ to implement better multi-threaded debugging support.
 //----------------------------------------------------------------------
 
 When reading thread registers, you currently need to set the current
-thread,then read the registers. This is kind of cumbersome, so we added the
+thread, then read the registers. This is kind of cumbersome, so we added the
 ability to query if the remote GDB server supports adding a "thread:<tid>;"
 suffix to all packets that request information for a thread. To test if the
 remote GDB server supports this feature:
@@ -720,7 +720,7 @@ for this region.
 //        the hex value of the register in debuggee endian byte order.
 //      - If key == "thread", then the value is the big endian hex
 //        thread-id of the stopped thread.
-//      - If key == "core", then value is a hex nujber of the core on
+//      - If key == "core", then value is a hex number of the core on
 //        which the stop was detected.
 //      - If key == "watch" or key == "rwatch" or key == "awatch", then
 //        value is the data address in big endian hex
@@ -790,7 +790,7 @@ for this region.
 //
 // BEST PRACTICES:
 //  Since register values can be supplied with this packet, it is often useful
-//  to return the PC, SP, FP, LR (if any), and FLAGS regsiters so that separate
+//  to return the PC, SP, FP, LR (if any), and FLAGS registers so that separate
 //  packets don't need to be sent to read each of these registers from each
 //  thread.
 //
@@ -799,7 +799,7 @@ for this region.
 //  "T" packet with "00" as the signal number and fill in as many key values 
 //  and registers as possible.
 //
-//  LLDB likes to know why a thread stopped since many thread contol 
+//  LLDB likes to know why a thread stopped since many thread control 
 //  operations like stepping over a source line, actually are implemented
 //  by running the process multiple times. If a breakpoint is hit while
 //  trying to step over a source line and LLDB finds out that a breakpoint
@@ -809,14 +809,14 @@ for this region.
 //  at the current PC and do an instruction single step, knowing that
 //  we stopped due to a "trace" helps us know that we can continue
 //  running versus stopping due to a "breakpoint" (if we have two 
-//  breakpoint instruction on consucutive instructions). So the more info
+//  breakpoint instruction on consecutive instructions). So the more info
 //  we can get about the reason a thread stops, the better job LLDB can
 //  do when controlling your process. A typical GDB server behavior is 
 //  to send a SIGTRAP for breakpoints _and_ also when instruction single
 //  stepping, in this case the debugger doesn't really know why we 
 //  stopped and it can make it hard for the debugger to control your
 //  program correctly. What if a real SIGTRAP was delivered to a thread
-//  while we were trying to single step? We woudn't know the difference
+//  while we were trying to single step? We wouldn't know the difference
 //  with a standard GDB remote server and we could do the wrong thing.
 //
 // PRIORITY TO IMPLEMENT

diff --git a/lldb/scripts/Python/interface/SBDebugger.i b/lldb/scripts/Python/interface/SBDebugger.i
index a27d280de7eb7f0a37ff534fd14de17f2758460b..43cc16e73949eed8681f1cea7bfff98607c965a7 100644 (file)
--- a/lldb/scripts/Python/interface/SBDebugger.i
+++ b/lldb/scripts/Python/interface/SBDebugger.i
@@ -87,7 +87,7 @@ if target:
                         #print value
                         print '%s (number of children = %d):' % (value.GetName(), value.GetNumChildren())
                         for child in value:
-                            print 'Name: ', child.GetName(), ' Value: ', child.GetValue(frame)
+                            print 'Name: ', child.GetName(), ' Value: ', child.GetValue()
 
             print 'Hit the breakpoint at main, enter to continue and wait for program to exit or \'Ctrl-D\'/\'quit\' to terminate the program'
             next = sys.stdin.readline()

diff --git a/lldb/www/python-reference.html b/lldb/www/python-reference.html
index cad447ba6e23457d06a22ff66c3ae06e782cb179..86edbc54cdc30499cb0609e3c3d115db63be9e02 100755 (executable)
--- a/lldb/www/python-reference.html
+++ b/lldb/www/python-reference.html
@@ -517,6 +517,11 @@ $2 = 0x000000010010aba0 Let's Be Friendsfoobar</tt></pre></code>
 <code><pre><tt><font color=green>#!/usr/bin/python</font>\r
 \r
 import lldb\r
+import os\r
+\r
+def disassemble_instructions(insts):\r
+    for i in insts:\r
+        print i\r
 \r
 <font color=green># Set the path to the executable to debug</font>\r
 exe = "./a.out"\r
@@ -550,30 +555,30 @@ if target:
         state = process.GetState ()\r
         print process\r
         if state == lldb.eStateStopped:\r
-        <font color=green># Get the first thread</font>\r
-        thread = process.GetThreadAtIndex (0)\r
-        if thread:\r
-            <font color=green># Print some simple thread info</font>\r
-            print thread\r
-            <font color=green># Get the first frame</font>\r
-            frame = thread.GetFrameAtIndex (0)\r
-            if frame:\r
-                <font color=green># Print some simple frame info</font>\r
-                print frame\r
-                function = frame.GetFunction()\r
-                <font color=green># See if we have debug info (a function)</font>\r
-                if function:\r
-                    <font color=green># We do have a function, print some info for the function</font>\r
-                    print function\r
-                    <font color=green># Now get all instructions for this function and print them</font>\r
-                    insts = function.GetInstructions(target)\r
-                    disassemble_instructions (insts)\r
-                else:\r
-                    <font color=green># See if we have a symbol in the symbol table for where we stopped</font>\r
-                    symbol = frame.GetSymbol();\r
-                    if symbol:\r
-                        <font color=green># We do have a symbol, print some info for the symbol</font>\r
-                        print symbol\r
+            <font color=green># Get the first thread</font>\r
+            thread = process.GetThreadAtIndex (0)\r
+            if thread:\r
+                <font color=green># Print some simple thread info</font>\r
+                print thread\r
+                <font color=green># Get the first frame</font>\r
+                frame = thread.GetFrameAtIndex (0)\r
+                if frame:\r
+                    <font color=green># Print some simple frame info</font>\r
+                    print frame\r
+                    function = frame.GetFunction()\r
+                    <font color=green># See if we have debug info (a function)</font>\r
+                    if function:\r
+                        <font color=green># We do have a function, print some info for the function</font>\r
+                        print function\r
+                        <font color=green># Now get all instructions for this function and print them</font>\r
+                        insts = function.GetInstructions(target)\r
+                        disassemble_instructions (insts)\r
+                    else:\r
+                        <font color=green># See if we have a symbol in the symbol table for where we stopped</font>\r
+                        symbol = frame.GetSymbol();\r
+                        if symbol:\r
+                            <font color=green># We do have a symbol, print some info for the symbol</font>\r
+                            print symbol\r
 </tt></pre></code>\r
                                        </div>\r
                                        <div class="postfooter"></div>\r