process being debugged in the TestBase.tearDown() instead of letting it continue
and finish.

llvm-svn: 112556

parameter.

llvm-svn: 112548

of os command to lldbtest.TestBase.system() method.

llvm-svn: 112547

them from test cases instead of issuing "make clean; make ..." os command.

llvm-svn: 112542

persistent variables were staying around too long.
This caused the following problem:

- A persistent result variable is created for the
  result of an expression.  The pointer to the
  corresponding Decl is stored in the variable.

- The persistent variable is looked up during
  struct generation (correctly) using its Decl.

- Another expression defines a new result variable
  which happens to have a Decl in the same place
  as the original result variable.

- The persistent variable is looked up during
  struct generation using its Decl, but the old
  result variable appears first in the list and
  has the same Decl pointer.

The fix is to destroy parser-specific data when
it is no longer valid.

Also improved some logging as I diagnosed the
bug.

llvm-svn: 112540

is launched with the -e option on Mac OS X.

llvm-svn: 112536

taken from Python 2.7's subprocess.check_output() convenience function.  The
purpose of this method is to run the os command with arguments and return its
output as a byte string.

Modified hello_world/TestHelloWorld.py to have two test cases:

o test_with_dsym_and_run_command
o test_with_dwarf_and_process_launch_api

with the dsym case conditioned on sys.platform.startswith("darwin") being true.
The two cases utilize the system() method to invoke "make clean; make MAKE_DYSM=YES/NO"
to prepare for the appropriate debugging format before running the test logic.

llvm-svn: 112530

storing pointers to objects inside a std::vector.
These objects can move around as the std::vector
changes, invalidating the pointers.

llvm-svn: 112527

Added a way to open the current source file & line in an external editor, and you can turn this on with:

lldb -e

llvm-svn: 112502

documentation. Symbol now inherits from the symbol
context scope so that the StackID can use a "SymbolContextScope *"
instead of a blockID (which could have been the same as some other
blockID from another symbol file). 

Modified the stacks that are created on subsequent stops to reuse
the previous stack frame objects which will allow for some internal
optimization using pointer comparisons during stepping. 

llvm-svn: 112495

llvm-svn: 112331

llvm-svn: 112328

breakpoint by FileSpec and line number and exercises some FileSpec APIs.

Also, RUN_STOPPED is a bad assert name, RUN_SUCCEEDED is better.

llvm-svn: 112327

debugger to insert self-contained functions for use by
expressions (mainly for error-checking).

In order to support detecting whether a crash occurred
in one of these helpers -- currently our preferred way
of reporting that an error-check failed -- added a bit
of support for getting the extent of a JITted function
in addition to just its base.

llvm-svn: 112324

llvm-svn: 112311

o Fixed a crasher when getting it via SBTarget.GetExecutable().

>>> filespec = target.GetExecutable()
Segmentation fault

o And renamed SBFileSpec::GetFileName() to GetFilename() to be consistent with FileSpec::GetFilename().

llvm-svn: 112308

swaps on the variable list, value object list, and disassembly. This avoids
us having to try and update frame indexes and other things that were getting
out of sync.

llvm-svn: 112301

llvm-svn: 112293

instead of trying to maintain the real frame list (unwind frames) and an
inline frame list. The information is cheap to produce when we already have
looked up a block and was making stack frame uniquing difficult when trying
to use the previous stack when making the current stack.

We now maintain the previous value object lists for common frames between
a previous and current frames so we will be able to tell when variable values
change.

llvm-svn: 112277

and process.  Added comment within the file about issues of using LaunchProcess
of SBTarget to launch a process (rdar://problem/8364687).

llvm-svn: 112276

The goal is to separate the parser's data from the data
belonging to the parser's clients.  This allows clients
to use the parser to obtain (for example) a JIT compiled
function or some DWARF code, and then discard the parser
state.

Previously, parser state was held in ClangExpression and
used liberally by ClangFunction, which inherited from
ClangExpression.  The main effects of this refactoring 
are:

- reducing ClangExpression to an abstract class that
  declares methods that any client must expose to the
  expression parser,

- moving the code specific to implementing the "expr"
  command from ClangExpression and
  CommandObjectExpression into ClangUserExpression,
  a new class,

- moving the common parser interaction code from
  ClangExpression into ClangExpressionParser, a new
  class, and

- making ClangFunction rely only on
  ClangExpressionParser and not depend on the
  internal implementation of ClangExpression.

Side effects include:

- the compiler interaction code has been factored
  out of ClangFunction and is now in an AST pass
  (ASTStructExtractor),

- the header file for ClangFunction is now fully
  documented,

- several bugs that only popped up when Clang was
  deallocated (which never happened, since the
  lifetime of the compiler was essentially infinite)
  are now fixed, and

- the developer-only "call" command has been
  disabled.

I have tested the expr command and the Objective-C
step-into code, which use ClangUserExpression and
ClangFunction, respectively, and verified that they
work.  Please let me know if you encounter bugs or
poor documentation.

llvm-svn: 112249

bt all

show the backtrace for all threads, and:

bt 1 3 4

show the backtrace for threads 1, 3 and 4.  If we want to come up with some fancier syntax for thread lists later, that will be great, but this will do for now.

llvm-svn: 112248

Added a utility method to TestBase class to debug print an SBValue object.

llvm-svn: 112247

Change the "-S", "-F" and "-M" options to take their arguments directly, rather than requiring the -n option.  This means you can't "or" together the types (i.e. set a breakpoint on a method or selector called "whatever".  But that is a pretty uncommon operation, and having to provide two flags for the more common "set a breakpoint on this selector" is annoying.

llvm-svn: 112245

llvm-svn: 112243

llvm-svn: 112236

llvm-svn: 112231

a section offset address.

Fixed up some very inefficient STL code.

llvm-svn: 112230

llvm-svn: 112226

llvm-svn: 112223

Change "Current" as in GetCurrentThread, GetCurrentStackFrame, etc, to "Selected" i.e. GetSelectedThread.  Selected makes more sense, since these are set by some user action (a selection).  I didn't change "CurrentProcess" since this is always controlled by the target, and a given target can only have one process, so it really can't be selected.

llvm-svn: 112221

llvm-svn: 112217

  with the only exception of launching the process from SBTarget which is under
  investigation.

o build-swig-Python.sh should also checks the timestamp of ${swig_input_file}
  for update eligibility.  Also, once an update is in order, there's no need
  to check the remaining header files for timestamps.

o Coaches swig to treat StopReason as an int type, instead of a C++ class.

llvm-svn: 112210

code stepping. Also we now store the stack frames for the current and previous
stops in the thread in std::auto_ptr objects. When we create a thread stack
frame list we pass the previous frame into it so it can re-use the frames
and maintain will allow for variable changes to be detected. I will implement
the stack frame reuse next.

llvm-svn: 112152

llvm-svn: 112103

o SBDebugger.GetCurrentTarget()
o SBTarget.GetProcess()
o SBProcess.GetAddressByteSize()

in order to make sure that, indeed, 64-bit, followed by 32-bit processes have
been launched.

Added invoke() method to TestBase to factor in the tracing logic in one place.
This method allows an object to call a method with no arg reflectively.

llvm-svn: 112102

there's no point matching further sub strings; the expect() already fails.

Also cleaned up the assert message for VARIABLES_DISPLAYED_CORRECTLY.

llvm-svn: 112074

mechanism seems to work fine on my MacBook Pro in some limited test cases.

The default maxLaunchCount and timeWait variables used in the scheme can be
overridden by the env variables LLDB_MAX_LAUNCH_COUNT and LLDB_TIME_WAIT.

llvm-svn: 112071

subclassing it anywhere.

llvm-svn: 112010

contains the entire stack backtrace.

llvm-svn: 112009