might dump file paths that allows the dumping of full paths or just the
basenames. Switched the stack frame dumping code to use just the basenames for
the files instead of the full path.

Modified the StackID class to no rely on needing the start PC for the current
function/symbol since we can use the SymbolContextScope to uniquely identify
that, unless there is no symbol context scope. In that case we can rely upon
the current PC value. This saves the StackID from having to calculate the 
start PC when the StackFrame::GetStackID() accessor is called.

Also improved the StackID less than operator to correctly handle inlined stack
frames in the same stack.

llvm-svn: 112867

method where they belong.  Also fixed a logic error in maintaining the command
interface flag (runStarted) indicating whether the lldb "run"/"process launch"
command has been issued.  It was erroneously cleared.

Modified the test cases to take advantage of the refactoring.

llvm-svn: 112863

llvm-svn: 112824

function statics, file globals and static variables) that a frame contains. 
The StackFrame objects can give out ValueObjects instances for
each variable which allows us to track when a variable changes and doesn't
depend on variable names when getting value objects.

StackFrame::GetVariableList now takes a boolean to indicate if we want to
get the frame compile unit globals and static variables.

The value objects in the stack frames can now correctly track when they have
been modified. There are a few more tweaks needed to complete this work. The
biggest issue is when stepping creates partial stacks (just frame zero usually)
and causes previous stack frames not to match up with the current stack frames
because the previous frames only has frame zero. We don't really want to 
require that all previous frames be complete since stepping often must check
stack frames to complete their jobs. I will fix this issue tomorrow.

llvm-svn: 112800

expressions.  If an expression dereferences an
invalid pointer, there will still be a crash -
just now the crash will be in the function
___clang_valid_pointer_check().

llvm-svn: 112785

llvm-svn: 112782

llvm-svn: 112750

llvm-svn: 112749

llvm-svn: 112732

Stream::Printf doesn't add a newline, so it needs to be added to all the error messages in CommandObjectExpression::EvaluateExpression.

llvm-svn: 112731

llvm-svn: 112725

expressions.  Values used by the expression are
checked by validation functions which cause the
program to crash if the values are unsafe.

Major changes:

- Added IRDynamicChecks.[ch], which contains the
  core code related to this feature

- Modified CommandObjectExpression to install the
  validator functions into the target process.

- Added an accessor to Process that gets/sets the
  helper functions

llvm-svn: 112690

llvm-svn: 112688

argument when issuing a "run" lldb command within the test case meant to
exercise the Python APIs, but is using the command interface due to certain
reason (such as target.LaunchProcess() does not reliably bring up the inferior).

llvm-svn: 112682

llvm-svn: 112679

llvm-svn: 112670

expectedFailure because in dwarf format, "variable list this" returns an error.

llvm-svn: 112660

llvm-svn: 112646

were not needed and fixed a merge issue.

llvm-svn: 112626

is disabled by default, and can be enabled using:

(lldb) set disable-aslr 0

llvm-svn: 112616

llvm-svn: 112614

llvm-svn: 112607

to delegate the building of binaries to a sys.platform-sepcific plugin.

Modified the dotest.py test driver to add the "plugins" directory to the
PYTHONPATH as well.

darwin.py is the Mac OS X plugin module.

llvm-svn: 112606

llvm-svn: 112558

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