From 4d3c008c7d1ec5a6ef0c4426c216c62d179df16d Mon Sep 17 00:00:00 2001 From: Daniel Malea Date: Tue, 12 Feb 2013 20:01:49 +0000 Subject: [PATCH] Fix document typos, indentation in python code, and API examples. Patch by Bruce Mitchener! llvm-svn: 175002 --- lldb/docs/code-signing.txt | 2 +- lldb/docs/lldb-for-gdb-users.txt | 4 +-- lldb/docs/lldb-gdb-remote.txt | 26 +++++++-------- lldb/scripts/Python/interface/SBDebugger.i | 2 +- lldb/www/python-reference.html | 53 ++++++++++++++++-------------- 5 files changed, 46 insertions(+), 41 deletions(-) diff --git a/lldb/docs/code-signing.txt b/lldb/docs/code-signing.txt index f1ba328..1c8220a 100644 --- 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 a45bc438..79f3473 100644 --- 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 d4136440..5aabb94 100644 --- 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:;" 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 a27d280..43cc16e 100644 --- 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 cad447b..86edbc5 100755 --- a/lldb/www/python-reference.html +++ b/lldb/www/python-reference.html @@ -517,6 +517,11 @@ $2 = 0x000000010010aba0 Let's Be Friendsfoobar 
#!/usr/bin/python
 
 import lldb
+import os
+
+def disassemble_instructions(insts):
+    for i in insts:
+        print i
 
 # Set the path to the executable to debug
 exe = "./a.out"
@@ -550,30 +555,30 @@ if target:
         state = process.GetState ()
         print process
         if state == lldb.eStateStopped:
-        # Get the first thread
-        thread = process.GetThreadAtIndex (0)
-        if thread:
-            # Print some simple thread info
-            print thread
-            # Get the first frame
-            frame = thread.GetFrameAtIndex (0)
-            if frame:
-                # Print some simple frame info
-                print frame
-                function = frame.GetFunction()
-                # See if we have debug info (a function)
-                if function:
-                    # We do have a function, print some info for the function
-                    print function
-                    # Now get all instructions for this function and print them
-                    insts = function.GetInstructions(target)
-                    disassemble_instructions (insts)
-                else:
-                    # See if we have a symbol in the symbol table for where we stopped
-                    symbol = frame.GetSymbol();
-                    if symbol:
-                        # We do have a symbol, print some info for the symbol
-                        print symbol
+            # Get the first thread
+            thread = process.GetThreadAtIndex (0)
+            if thread:
+                # Print some simple thread info
+                print thread
+                # Get the first frame
+                frame = thread.GetFrameAtIndex (0)
+                if frame:
+                    # Print some simple frame info
+                    print frame
+                    function = frame.GetFunction()
+                    # See if we have debug info (a function)
+                    if function:
+                        # We do have a function, print some info for the function
+                        print function
+                        # Now get all instructions for this function and print them
+                        insts = function.GetInstructions(target)
+                        disassemble_instructions (insts)
+                    else:
+                        # See if we have a symbol in the symbol table for where we stopped
+                        symbol = frame.GetSymbol();
+                        if symbol:
+                            # We do have a symbol, print some info for the symbol
+                            print symbol
-- 2.7.4