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

functionality into StackFrameList. This will allow us to copy the previous
stack backtrace from the previous stop into another variable so we can re-use
as much as possible from the previous stack backtrace.

llvm-svn: 112007

llvm-svn: 112000

correctly after all.  It was my own configuration error (I was building x86_64
only).

llvm-svn: 111992

has inlined functions that all started at the same address, then the inlined
backtrace would not produce correct stack frames.

Also cleaned up and inlined a lot of stuff in lldb_private::Address.

Added a function to StackFrame to detect if the frame is a concrete frame so
we can detect the difference between actual frames and inlined frames.

llvm-svn: 111989

currently fails: rdar://problem/8349784.

Forgot to check in lldbtest.py in the previous commit r111958.

llvm-svn: 111975

complex inlined examples.

StackFrame classes don't have a "GetPC" anymore, they have "GetFrameCodeAddress()".
This is because inlined frames will have a PC value that is the same as the 
concrete frame that owns the inlined frame, yet the code locations for the
frame can be different. We also need to be able to get the real PC value for
a given frame so that variables evaluate correctly. To get the actual PC
value for a frame you can use:

    addr_t pc = frame->GetRegisterContext()->GetPC();

Some issues with the StackFrame stomping on its own symbol context were 
resolved which were causing the information to change for a frame when the
stack ID was calculated. Also the StackFrame will now correctly store the
symbol context resolve flags for any extra bits of information that were 
looked up (if you ask for a block only and you find one, you will alwasy have
the compile unit and function).

llvm-svn: 111964

llvm-svn: 111961