forked from OSchip/llvm-project
Fix document typos, indentation in python code, and API examples.
Patch by Bruce Mitchener! llvm-svn: 175002
This commit is contained in:
Daniel Malea
parent
f377160d2f
commit
4d3c008c7d
lldb
docs
scripts/Python/interface
www
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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()
|
||||
|
|
|
|||
|
|
@ -517,6 +517,11 @@ $2 = 0x000000010010aba0 Let's Be Friendsfoobar</tt></pre></code>
|
|||
<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>
|
||||
|
|
|
|||
Loading…
Reference in New Issue