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

llvm-svn: 112750

llvm-svn: 112749

llvm-svn: 112732

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: 112670

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

llvm-svn: 112660

llvm-svn: 112646

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

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

llvm-svn: 112556

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

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

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

llvm-svn: 112311

llvm-svn: 112293

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

llvm-svn: 112276

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

llvm-svn: 112247

llvm-svn: 112236

llvm-svn: 112231

llvm-svn: 112226

llvm-svn: 112223

  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

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

llvm-svn: 112000

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

llvm-svn: 111992

currently fails: rdar://problem/8349784.

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

llvm-svn: 111975

llvm-svn: 111961

llvm-svn: 111960

llvm-svn: 111958

llvm-svn: 111939

llvm-svn: 111938

"variable list bits" display bits variable correctly, but not "variable list".

llvm-svn: 111937