Blame - www/python-reference.html - fp2-dev/platform/external/lldb

2012-01-24 02:40:42 +0000

[diff] [blame]

85

The embedded python interpreter can be accessed in a variety of ways from within LLDB. The

86

easiest way is to use the lldb command script with no arguments at the lldb command prompt:

Greg Clayton

2012-01-22 02:55:08 +0000

[diff] [blame]

87

<code><pre><tt>(lldb) script

88

Python Interactive Interpreter. To exit, type 'quit()', 'exit()' or Ctrl-D.

>>> 2+3

5

>>> hex(12345)

'0x3039'

>>>

</tt></pre></code>

Jim Ingham

2012-01-24 02:40:42 +0000

[diff] [blame]

96

This drops you into the embedded python interpreter. When running under the script command,

97

lldb sets some convenience variables that give you quick access to the currently selected entities that characterize

98

the program and debugger state. In each case, if there is no currently selected entity of the appropriate

Enrico Granata

b1052dc

2013-01-16 22:25:17 +0000

[diff] [blame]

99

type, the variable's IsValid method will return false. These variables are:

100

Greg Clayton

2012-01-22 02:55:08 +0000

[diff] [blame]

101

102

<tr>

103

<td class="hed" width="20%">Variable</td>

104

105

<td class="hed" width="70%">Description</td>

</tr>

<tr>

lldb.debugger

</td>

lldb.SBDebugger

</td>

Jim Ingham

2012-01-24 02:40:42 +0000

[diff] [blame]

116

Contains the debugger object whose script command was invoked.

117

The lldb.SBDebugger object owns the command interpreter

118

and all the targets in your debug session. There will always be a

119

Debugger in the embedded interpreter.

Greg Clayton

2012-01-22 02:55:08 +0000

[diff] [blame]

</td>

</tr>

<tr>

lldb.target

</td>

lldb.SBTarget

</td>

Jim Ingham

2012-01-24 02:40:42 +0000

[diff] [blame]

130

Contains the currently selected target - for instance the one made with the

131

file or selected by the target select <target-index> command.

132

The lldb.SBTarget manages one running process, and all the executable

133

and debug files for the process.

Greg Clayton

2012-01-22 02:55:08 +0000

[diff] [blame]

</td>

</tr>

<tr>

lldb.process

</td>

lldb.SBProcess

</td>

Jim Ingham

2012-01-24 02:40:42 +0000

[diff] [blame]

144

Contains the process of the currently selected target.

145

The lldb.SBProcess object manages the threads and allows access to

146

memory for the process.

Greg Clayton

2012-01-22 02:55:08 +0000

[diff] [blame]

</td>

</tr>

<tr>

lldb.thread

</td>

lldb.SBThread

</td>

Jim Ingham

2012-01-24 02:40:42 +0000

[diff] [blame]

157

Contains the currently selected thread.

158

The lldb.SBThread object manages the stack frames in that thread.

Greg Clayton

2012-01-22 02:55:08 +0000

[diff] [blame]

159

A thread is always selected in the command interpreter when a target stops.

Enrico Granata

b1052dc

2013-01-16 22:25:17 +0000

[diff] [blame]

160

The thread select <thread-index> command can be used to change the

Jim Ingham

2012-01-24 02:40:42 +0000

[diff] [blame]

161

currently selected thread. So as long as you have a stopped process, there will be

162

some selected thread.

Greg Clayton

2012-01-22 02:55:08 +0000

[diff] [blame]

</td>

</tr>

<tr>

lldb.frame

</td>

lldb.SBFrame

</td>

Jim Ingham

2012-01-24 02:40:42 +0000

[diff] [blame]

173

Contains the currently selected stack frame.

174

The lldb.SBFrame object manage the stack locals and the register set for

175

that stack.

Greg Clayton

2012-01-22 02:55:08 +0000

[diff] [blame]

176

A stack frame is always selected in the command interpreter when a target stops.

Enrico Granata

b1052dc

2013-01-16 22:25:17 +0000

[diff] [blame]

177

The frame select <frame-index> command can be used to change the

Jim Ingham

2012-01-24 02:40:42 +0000

[diff] [blame]

178

currently selected frame. So as long as you have a stopped process, there will

179

be some selected frame.

Greg Clayton

2012-01-22 02:55:08 +0000

[diff] [blame]

</td>

</tr>

</table>

Enrico Granata

2013-01-16 22:25:17 +0000

[diff] [blame]

184

While extremely convenient, these variables have a couple caveats that you should be aware of.

185

First of all, they hold the values

186

of the selected objects on entry to the embedded interpreter. They do not update as you use the LLDB

187

API's to change, for example, the currently selected stack frame or thread.

188

Moreover, they are only defined and meaningful while in the interactive Python interpreter.

189

There is no guarantee on their value in any other situation, hence you should not use them when defining

190

Python formatters, breakpoint scripts and commands (or any other Python extension point that LLDB provides).

191

As a rationale for such behavior, consider that lldb can

192

run in a multithreaded environment, and another thread might call the "script" command, changing the value out

193

from under you.

194

195

To get started with these objects and LLDB scripting, please note that almost

Jim Ingham

2012-01-24 02:40:42 +0000

[diff] [blame]

196

all of the lldb Python objects are able to briefly describe themselves when you pass them

197

to the Python print function:

Greg Clayton

2012-01-22 02:55:08 +0000

[diff] [blame]

198

<code><pre><tt>(lldb) script

199

Python Interactive Interpreter. To exit, type 'quit()', 'exit()' or Ctrl-D.

200

>>> print lldb.debugger

201

Debugger (instance: "debugger_1", id: 1)

202

>>> print lldb.target

203

a.out

204

>>> print lldb.process

205

SBProcess: pid = 59289, state = stopped, threads = 1, executable = a.out

206

>>> print lldb.thread

207

SBThread: tid = 0x1f03

208

>>> print lldb.frame

209

frame #0: 0x0000000100000bb6 a.out main + 54 at main.c:16

</tt></pre></code>

</div>

</div>

<h1 class ="postheader">Running a Python script when a breakpoint gets hit</h1>

218

219

Jim Ingham

2012-01-24 02:40:42 +0000

[diff] [blame]

220

One very powerful use of the lldb Python API is to have a python script run when a breakpoint gets hit. Adding python

Greg Clayton

2012-01-22 02:55:08 +0000

[diff] [blame]

221

scripts to breakpoints provides a way to create complex breakpoint

222

conditions and also allows for smart logging and data gathering.

Jim Ingham

2012-01-24 02:40:42 +0000

[diff] [blame]

223

When your process hits a breakpoint to which you have attached some python code, the code is executed as the

Greg Clayton

b34ca85

2012-10-26 17:53:21 +0000

[diff] [blame]

224

body of a function which takes three arguments:

Greg Clayton

2012-01-22 02:55:08 +0000

[diff] [blame]

225

Greg Clayton

b34ca85

2012-10-26 17:53:21 +0000

[diff] [blame]

226

<code><pre><tt>def breakpoint_function_wrapper(frame, bp_loc, dict):

Greg Clayton

2012-01-22 02:55:08 +0000

[diff] [blame]

227

# Your code goes here

</tt></pre></code>

<tr>

<td class="hed" width="10%">Argument</td>

232

233

<td class="hed" width="80%">Description</td>

</tr>

<tr>

frame

</td>

lldb.SBFrame

</td>

The current stack frame where the breakpoint got hit.

Jim Ingham

2012-01-24 02:40:42 +0000

[diff] [blame]

245

The object will always be valid.

Greg Clayton

2012-01-22 02:55:08 +0000

[diff] [blame]

246

This frame argument might not match the currently selected stack frame found in the lldb module global variable lldb.frame.

</td>

</tr>

<tr>

bp_loc

</td>

lldb.SBBreakpointLocation

255

</td>

256

257

The breakpoint location that just got hit. Breakpoints are represented by lldb.SBBreakpoint

258

objects. These breakpoint objects can have one or more locations. These locations

259

are represented by lldb.SBBreakpointLocation objects.

260

</td>

261

</tr>

Greg Clayton

b34ca85

2012-10-26 17:53:21 +0000

[diff] [blame]

<tr>

dict

</td>

dict

</td>

The python session dictionary as a standard python dictionary object.

271

</td>

272

</tr>

Greg Clayton

2012-01-22 02:55:08 +0000

[diff] [blame]

273

</table>

Enrico Granata

5c7c781

2013-05-16 23:17:25 +0000

[diff] [blame]

274

Optionally, a Python breakpoint command can return a value. Returning False tells LLDB that you do not want to stop at the breakpoint.

275

Any other return value (including None or leaving out the return statement altogether) is akin to telling LLDB to actually stop at the breakpoint.

276

This can be useful in situations where a breakpoint only needs to stop the process when certain conditions are met, and you do not want to inspect the

277

program state manually at every stop and then continue.

Jim Ingham

2012-01-24 02:40:42 +0000

[diff] [blame]

278

An example will show how simple it is to write some python code and attach it to a breakpoint.

279

The following example will allow you to track the order in which the functions in a given shared library

280

are first executed during one run of your program. This is a simple method to gather an order file which

281

can be used to optimize function placement within a binary for execution locality.

282

We do this by setting a regular expression breakpoint

283

that will match every function in the shared library. The regular expression '.' will match

284

any string that has at least one character in it, so we will use that.

Greg Clayton

2012-01-22 02:55:08 +0000

[diff] [blame]

285

This will result in one lldb.SBBreakpoint object

Jim Ingham

2012-01-24 02:40:42 +0000

[diff] [blame]

286

that contains an lldb.SBBreakpointLocation object for each function. As the breakpoint gets

287

hit, we use a counter to track the order in which the function at this particular breakpoint location got hit.

288

Since our code is passed the location that was hit, we can get the name of the function from the location,

289

disable the location so we won't count this function again; then log some info and continue the process.

290

Note we also have to initialize our counter, which we do with the simple one-line version of the script

command.

Here is the code:

Greg Clayton

2012-01-22 02:55:08 +0000

[diff] [blame]

294

<code><pre><tt>(lldb) breakpoint set --func-regex=. --shlib=libfoo.dylib

295

Breakpoint created: 1: regex = '.', module = libfoo.dylib, locations = 223

Jim Ingham

2012-01-24 02:40:42 +0000

[diff] [blame]

296

(lldb) script counter = 0

Greg Clayton

2012-01-22 02:55:08 +0000

[diff] [blame]

297

(lldb) breakpoint command add --script-type python 1

298

Enter your Python command(s). Type 'DONE' to end.

Jim Ingham

2012-01-24 02:40:42 +0000

[diff] [blame]

299

> # Increment our counter. Since we are in a function, this must be a global python variable

300

> global counter

301

> counter += 1

Greg Clayton

2012-01-22 02:55:08 +0000

[diff] [blame]

302

> # Get the name of the function

303

> name = frame.GetFunctionName()

304

> # Print the order and the function name

Jim Ingham

2012-01-24 02:40:42 +0000

[diff] [blame]

305

> print '[%i] %s' % (counter, name)

Greg Clayton

2012-01-22 02:55:08 +0000

[diff] [blame]

306

> # Disable the current breakpoint location so it doesn't get hit again

307

> bp_loc.SetEnabled(False)

Enrico Granata

f812f62

2013-05-31 22:54:23 +0000

[diff] [blame]

308

> # No need to stop here

309

> return False

Greg Clayton

2012-01-22 02:55:08 +0000

[diff] [blame]

310

> DONE

311

</tt></pre></code>

312

The breakpoint command add command above attaches a python script to breakpoint 1.

313

To remove the breakpoint command:

314

<code>(lldb) breakpoint command delete 1</code>

</div>

</div>

<h1 class ="postheader">Create a new LLDB command using a python function</h1>

319

320

Jim Ingham

2012-01-24 02:40:42 +0000

[diff] [blame]

321

Python functions can be used to create new LLDB command interpreter commands, which will work

322

like all the natively defined lldb commands. This provides a very flexible and easy way to extend LLDB to meet your

Greg Clayton

2012-01-22 02:55:08 +0000

[diff] [blame]

323

debugging requirements.

Jim Ingham

2012-01-24 02:40:42 +0000

[diff] [blame]

324

To write a python function that implements a new LDB command define the function to take four arguments as follows:

Greg Clayton

2012-01-22 02:55:08 +0000

[diff] [blame]

325

Enrico Granata

2012-08-08 02:06:30 +0000

[diff] [blame]

326

<code><pre><tt>def command_function(debugger, command, result, internal_dict):

Greg Clayton

2012-01-22 02:55:08 +0000

[diff] [blame]

327

# Your code goes here

328

</tt></pre></code>

Enrico Granata

c0791aa

2012-05-02 21:00:41 +0000

[diff] [blame]

329

330

Optionally, you can also provide a Python docstring, and LLDB will use it when providing help for your command, as in:

Enrico Granata

2012-08-08 02:06:30 +0000

[diff] [blame]

331

<code><pre><tt>def command_function(debugger, command, result, internal_dict):

Enrico Granata

c0791aa

2012-05-02 21:00:41 +0000

[diff] [blame]

332

"""This command takes a lot of options and does many fancy things"""

333

# Your code goes here

334

</tt></pre></code>

335

Greg Clayton

2012-01-22 02:55:08 +0000

[diff] [blame]

336

337

<tr>

338

<td class="hed" width="10%">Argument</td>

339

340

<td class="hed" width="80%">Description</td>

</tr>

<tr>

debugger

</td>

lldb.SBDebugger

</td>

The current debugger object.

</td>

</tr>

<tr>

command

</td>

python string

</td>

A python string containing all arguments for your command. If you need to chop up the arguments

363

try using the shlex module's <code>shlex.split(command)</code> to properly extract the

arguments.

</td>

</tr>

<tr>

result

</td>

lldb.SBCommandReturnObject

373

</td>

374

Enrico Granata

f734066

2013-03-25 17:37:39 +0000

[diff] [blame]

375

A return object which encapsulates success/failure information for the command and output text

376

that needs to be printed as a result of the command. The plain Python "print" command also works but

377

text won't go in the result by default (it is useful as a temporary logging facility).

Greg Clayton

2012-01-22 02:55:08 +0000

[diff] [blame]

</td>

</tr>

<tr>

Enrico Granata

2012-08-08 02:06:30 +0000

[diff] [blame]

382

internal_dict

Greg Clayton

2012-01-22 02:55:08 +0000

[diff] [blame]

</td>

python dict object

</td>

The dictionary for the current embedded script session which contains all variables

and functions.

</td>

</tr>

</table>

Enrico Granata

f734066

2013-03-25 17:37:39 +0000

[diff] [blame]

393

As a convenience, you can treat the result object as a Python file object, and say

Enrico Granata

f812f62

2013-05-31 22:54:23 +0000

[diff] [blame]

394

<code><pre><tt>print >>result, "my command does lots of cool stuff"</tt></pre></code>

395

SBCommandReturnObject and SBStream

Enrico Granata

f734066

2013-03-25 17:37:39 +0000

[diff] [blame]

396

both support this file-like behavior by providing write() and flush() calls at the Python layer.

Jim Ingham

2012-01-24 02:40:42 +0000

[diff] [blame]

397

One other handy convenience when defining lldb command-line commands is the command

398

command script import which will import a module specified by file path - so you

399

don't have to change your PYTHONPATH for temporary scripts. It also has another convenience

400

that if your new script module has a function of the form:

401

Enrico Granata

2012-08-08 02:06:30 +0000

[diff] [blame]

402

<code><pre><tt>def __lldb_init_module(debugger, internal_dict):

Greg Clayton

261c974

2012-01-26 05:36:07 +0000

[diff] [blame]

403

# Command Initialization code goes here

404

</tt></pre></code>

Jim Ingham

2012-01-24 02:40:42 +0000

[diff] [blame]

405

Enrico Granata

2012-08-08 02:06:30 +0000

[diff] [blame]

406

where debugger and internal_dict are as above, that function will get run when the module is loaded

Greg Clayton

261c974

2012-01-26 05:36:07 +0000

[diff] [blame]

407

allowing you to add whatever commands you want into the current debugger. Note that

408

this function will only be run when using the LLDB comand command script import,

409

it will not get run if anyone imports your module from another module.

410

If you want to always run code when your module is loaded from LLDB

411

or when loaded via an import statement in python code

412

you can test the lldb.debugger object, since you imported the

413

<lldb> module at the top of the python ls.py module. This test

414

must be in code that isn't contained inside of any function or class,

415

just like the standard test for __main__ like all python modules

416

usally do. Sample code would look like:

417

418

<code><pre><tt>if __name__ == '__main__':

419

# Create a new debugger instance in your module if your module

420

# can be run from the command line. When we run a script from

421

# the command line, we won't have any debugger object in

422

# lldb.debugger, so we can just create it if it will be needed

423

lldb.debugger = lldb.SBDebugger.Create()

424

elif lldb.debugger:

425

# Module is being run inside the LLDB interpreter

426

lldb.debugger.HandleCommand('command script add -f ls.ls ls')

427

print 'The "ls" python command has been installed and is ready for use.'

428

</tt></pre></code>

429

Now we can create a module called ls.py in the file ~/ls.py that will implement a function that

Jim Ingham

2012-01-24 02:40:42 +0000

[diff] [blame]

430

can be used by LLDB's python command code:

Greg Clayton

2012-01-22 02:55:08 +0000

[diff] [blame]

431

432

<code><pre><tt>#!/usr/bin/python

import lldb

import commands

import optparse

import shlex

Enrico Granata

2012-08-08 02:06:30 +0000

[diff] [blame]

439

def ls(debugger, command, result, internal_dict):

Enrico Granata

b89642b

2013-07-11 21:49:38 +0000

[diff] [blame]

440

print >>result, (commands.getoutput('/bin/ls %s' % command))

Greg Clayton

2012-01-22 02:55:08 +0000

[diff] [blame]

441

Jim Ingham

2012-01-24 02:40:42 +0000

[diff] [blame]

442

# And the initialization code to add your commands

Enrico Granata

2012-08-08 02:06:30 +0000

[diff] [blame]

443

def __lldb_init_module(debugger, internal_dict):

Jim Ingham

2012-01-24 02:40:42 +0000

[diff] [blame]

444

debugger.HandleCommand('command script add -f ls.ls ls')

Greg Clayton

2012-01-22 02:55:08 +0000

[diff] [blame]

445

print 'The "ls" python command has been installed and is ready for use.'

446

</tt></pre></code>

447

Now we can load the module into LLDB and use it

448

<code><pre><tt>% lldb

Greg Clayton

261c974

2012-01-26 05:36:07 +0000

[diff] [blame]

449

(lldb) command script import ~/ls.py

Greg Clayton

2012-01-22 02:55:08 +0000

[diff] [blame]

450

The "ls" python command has been installed and is ready for use.

451

(lldb) ls -l /tmp/

452

total 365848

453

-rw-r--r--@ 1 someuser wheel 6148 Jan 19 17:27 .DS_Store

454

-rw------- 1 someuser wheel 7331 Jan 19 15:37 crash.log

455

</tt></pre></code>

Enrico Granata

ac39f3c

2013-05-09 01:32:24 +0000

[diff] [blame]

456

A more interesting template has been created in the source repository that can help you to create

Greg Clayton

2012-01-22 02:55:08 +0000

[diff] [blame]

457

lldb command quickly:

458

<a href="http://llvm.org/svn/llvm-project/lldb/trunk/examples/python/cmdtemplate.py">cmdtemplate.py</a>

Enrico Granata

74566c9

2012-08-24 21:20:14 +0000

[diff] [blame]

459

460

A commonly required facility is being able to create a command that does some token substitution, and then runs a different debugger command

461

(usually, it po'es the result of an expression evaluated on its argument). For instance, given the following program:

462

463

#import <Foundation/Foundation.h>

464

NSString*

465

ModifyString(NSString* src)

466

{

467

return [src stringByAppendingString:@"foobar"];

}

int main()

{

NSString* aString = @"Hello world";

473

NSString* anotherString = @"Let's be friends";

return 1;

}

</tt></pre></code>

you may want a pofoo X command, that equates po [ModifyString(X) capitalizedString].

478

The following debugger interaction shows how to achieve that goal:

479

480

(lldb) script

481

Python Interactive Interpreter. To exit, type 'quit()', 'exit()' or Ctrl-D.

482

>>> def pofoo_funct(debugger, command, result, internal_dict):

483

... cmd = "po [ModifyString(" + command + ") capitalizedString]"

484

... lldb.debugger.HandleCommand(cmd)

485

...

486

>>> ^D

487

(lldb) command script add pofoo -f pofoo_funct

488

(lldb) pofoo aString

489

$1 = 0x000000010010aa00 Hello Worldfoobar

490

(lldb) pofoo anotherString

491

$2 = 0x000000010010aba0 Let's Be Friendsfoobar</tt></pre></code>

Greg Clayton

2012-01-22 02:55:08 +0000

[diff] [blame]

492

</div>

493

494

<h1 class ="postheader">Using the lldb.py module in python</h1>

495

496

497

LLDB has all of its core code build into a shared library which gets

498

used by the lldb command line application. On Mac OS X this

499

shared library is a framework: LLDB.framework and on other

Jim Ingham

2012-01-24 02:40:42 +0000

[diff] [blame]

500

unix variants the program is a shared library: lldb.so. LLDB also

501

provides an lldb.py module that contains the bindings from LLDB into Python.

502

To use the

503

LLDB.framework to create your own stand-alone python programs, you will

Greg Clayton

2012-01-22 02:55:08 +0000

[diff] [blame]

504

need to tell python where to look in order to find this module. This

Jim Ingham

2012-01-24 02:40:42 +0000

[diff] [blame]

505

is done by setting the PYTHONPATH environment variable, adding

506

a path to the directory that contains the lldb.py python module. On

507

Mac OS X, this is contained inside the LLDB.framework, so you would do:

Greg Clayton

2012-01-22 02:55:08 +0000

[diff] [blame]

508

509

For csh and tcsh:

510

<code>% setenv PYTHONPATH /Developer/Library/PrivateFrameworks/LLDB.framework/Resources/Python</code>

511

For sh and bash:

512

<code>% export PYTHONPATH=/Developer/Library/PrivateFrameworks/LLDB.framework/Resources/Python</code>

513

Jim Ingham

2012-01-24 02:40:42 +0000

[diff] [blame]

514

Alternately, you can append the LLDB Python directory to the sys.path list directly in

515

your Python code before importing the lldb module.

516

Greg Clayton

2012-01-22 02:55:08 +0000

[diff] [blame]

517

518

Now your python scripts are ready to import the lldb module. Below is a

519

python script that will launch a program from the current working directory

520

called "a.out", set a breakpoint at "main", and then run and hit the breakpoint,

521

and print the process, thread and frame objects if the process stopped:

522

523

524

<code><pre><tt>#!/usr/bin/python

525

526

import lldb

Daniel Malea

7a87d52

2013-02-12 20:01:49 +0000

[diff] [blame]

527

import os

528

529

def disassemble_instructions(insts):

530

for i in insts:

531

print i

Greg Clayton

2012-01-22 02:55:08 +0000

[diff] [blame]

532

533

# Set the path to the executable to debug

534

exe = "./a.out"

535

536

# Create a new debugger instance

537

debugger = lldb.SBDebugger.Create()

538

539

# When we step or continue, don't return from the function until the process

Jim Ingham

2012-01-24 02:40:42 +0000

[diff] [blame]

540

# stops. Otherwise we would have to handle the process events ourselves which, while doable is

541

#a little tricky. We do this by setting the async mode to false.

Greg Clayton

2012-01-22 02:55:08 +0000

[diff] [blame]

542

debugger.SetAsync (False)

543

544

# Create a target from a file and arch

545

print "Creating a target for '%s'" % exe

546

547

target = debugger.CreateTargetWithFileAndArch (exe, lldb.LLDB_ARCH_DEFAULT)

548

549

if target:

550

# If the target is valid set a breakpoint at main

551

main_bp = target.BreakpointCreateByName ("main", target.GetExecutable().GetFilename());

print main_bp

# Launch the process. Since we specified synchronous mode, we won't return

556

# from this function until we hit the breakpoint at main

557

process = target.LaunchSimple (None, None, os.getcwd())

558

559

# Make sure the launch went ok

560

if process:

561

# Print some simple process info

562

state = process.GetState ()

563

print process

564

if state == lldb.eStateStopped:

Daniel Malea

7a87d52

2013-02-12 20:01:49 +0000

[diff] [blame]

565

# Get the first thread

566

thread = process.GetThreadAtIndex (0)

567

if thread:

568

# Print some simple thread info

569

print thread

570

# Get the first frame

571

frame = thread.GetFrameAtIndex (0)

572

if frame:

573

# Print some simple frame info

574

print frame

575

function = frame.GetFunction()

576

# See if we have debug info (a function)

577

if function:

578

# We do have a function, print some info for the function

579

print function

580

# Now get all instructions for this function and print them

581

insts = function.GetInstructions(target)

582

disassemble_instructions (insts)

583

else:

584

# See if we have a symbol in the symbol table for where we stopped

585

symbol = frame.GetSymbol();

586

if symbol:

587

# We do have a symbol, print some info for the symbol

588

print symbol

Greg Clayton