[Lldb-commits] [lldb] r175002 - Fix document typos, indentation in python code, and API examples.

Daniel Malea daniel.malea at intel.com
Tue Feb 12 12:01:49 PST 2013


Author: dmalea
Date: Tue Feb 12 14:01:49 2013
New Revision: 175002

URL: http://llvm.org/viewvc/llvm-project?rev=175002&view=rev
Log:
Fix document typos, indentation in python code, and API examples.

Patch by Bruce Mitchener!



Modified:
    lldb/trunk/docs/code-signing.txt
    lldb/trunk/docs/lldb-for-gdb-users.txt
    lldb/trunk/docs/lldb-gdb-remote.txt
    lldb/trunk/scripts/Python/interface/SBDebugger.i
    lldb/trunk/www/python-reference.html

Modified: lldb/trunk/docs/code-signing.txt
URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/docs/code-signing.txt?rev=175002&r1=175001&r2=175002&view=diff
==============================================================================
--- lldb/trunk/docs/code-signing.txt (original)
+++ lldb/trunk/docs/code-signing.txt Tue Feb 12 14:01:49 2013
@@ -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.

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=175002&r1=175001&r2=175002&view=diff
==============================================================================
--- lldb/trunk/docs/lldb-for-gdb-users.txt (original)
+++ lldb/trunk/docs/lldb-for-gdb-users.txt Tue Feb 12 14:01:49 2013
@@ -204,7 +204,7 @@ Enter your debugger command(s).  Type 'D
 > 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 *) 0x00000001001354
 
 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

Modified: lldb/trunk/docs/lldb-gdb-remote.txt
URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/docs/lldb-gdb-remote.txt?rev=175002&r1=175001&r2=175002&view=diff
==============================================================================
--- lldb/trunk/docs/lldb-gdb-remote.txt (original)
+++ lldb/trunk/docs/lldb-gdb-remote.txt Tue Feb 12 14:01:49 2013
@@ -27,7 +27,7 @@ added above and beyond the standard GDB
 //  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 dis
                 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
 //  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
 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
 
 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 debug
 //----------------------------------------------------------------------
 
 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

Modified: lldb/trunk/scripts/Python/interface/SBDebugger.i
URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/scripts/Python/interface/SBDebugger.i?rev=175002&r1=175001&r2=175002&view=diff
==============================================================================
--- lldb/trunk/scripts/Python/interface/SBDebugger.i (original)
+++ lldb/trunk/scripts/Python/interface/SBDebugger.i Tue Feb 12 14:01:49 2013
@@ -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()

Modified: lldb/trunk/www/python-reference.html
URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/www/python-reference.html?rev=175002&r1=175001&r2=175002&view=diff
==============================================================================
--- lldb/trunk/www/python-reference.html (original)
+++ lldb/trunk/www/python-reference.html Tue Feb 12 14:01:49 2013
@@ -517,6 +517,11 @@ $2 = 0x000000010010aba0 Let's Be Friends
 <code><pre><tt><font color=green>#!/usr/bin/python</font>
 
 import lldb
+import os
+
+def disassemble_instructions(insts):
+    for i in insts:
+        print i
 
 <font color=green># Set the path to the executable to debug</font>
 exe = "./a.out"
@@ -550,30 +555,30 @@ if target:
         state = process.GetState ()
         print process
         if state == lldb.eStateStopped:
-        <font color=green># Get the first thread</font>
-        thread = process.GetThreadAtIndex (0)
-        if thread:
-            <font color=green># Print some simple thread info</font>
-            print thread
-            <font color=green># Get the first frame</font>
-            frame = thread.GetFrameAtIndex (0)
-            if frame:
-                <font color=green># Print some simple frame info</font>
-                print frame
-                function = frame.GetFunction()
-                <font color=green># See if we have debug info (a function)</font>
-                if function:
-                    <font color=green># We do have a function, print some info for the function</font>
-                    print function
-                    <font color=green># Now get all instructions for this function and print them</font>
-                    insts = function.GetInstructions(target)
-                    disassemble_instructions (insts)
-                else:
-                    <font color=green># See if we have a symbol in the symbol table for where we stopped</font>
-                    symbol = frame.GetSymbol();
-                    if symbol:
-                        <font color=green># We do have a symbol, print some info for the symbol</font>
-                        print symbol
+            <font color=green># Get the first thread</font>
+            thread = process.GetThreadAtIndex (0)
+            if thread:
+                <font color=green># Print some simple thread info</font>
+                print thread
+                <font color=green># Get the first frame</font>
+                frame = thread.GetFrameAtIndex (0)
+                if frame:
+                    <font color=green># Print some simple frame info</font>
+                    print frame
+                    function = frame.GetFunction()
+                    <font color=green># See if we have debug info (a function)</font>
+                    if function:
+                        <font color=green># We do have a function, print some info for the function</font>
+                        print function
+                        <font color=green># Now get all instructions for this function and print them</font>
+                        insts = function.GetInstructions(target)
+                        disassemble_instructions (insts)
+                    else:
+                        <font color=green># See if we have a symbol in the symbol table for where we stopped</font>
+                        symbol = frame.GetSymbol();
+                        if symbol:
+                            <font color=green># We do have a symbol, print some info for the symbol</font>
+                            print symbol
 </tt></pre></code>
         				</div>
         				<div class="postfooter"></div>





More information about the lldb-commits mailing list