llvm-svn: 116950

llvm-svn: 116941

parent call frame information.  And comment out the check for stop reason for the
time being.  The stop reason disappeared from the "thread backtrace" output for
breakpoint stop with condition.

llvm-svn: 116939

invocations of them into session object.

Remove a debug statement.

llvm-svn: 116938

llvm-svn: 116936

to be run during tearDown() to effect the restore action instead of executing it inline
during the test method, because the test may already fail and bailout before the inline
restore action.

Fix test_set_output_path() and pass_run_args_and_env_vars() to use this mechanism.

llvm-svn: 116881

llvm-svn: 116874

after running the program.

llvm-svn: 116873

llvm-svn: 116850

Add a little helper function SETTING_MSG(setting) to be used from TestSettings.test_set_output_path().

llvm-svn: 116847

llvm-svn: 116844

Change the environment variable name to be more descriptive from LLDB_TIME_WAIT to LLDB_TIME_WAIT_NEXT_LAUNCH.

llvm-svn: 116809

to 'expression' to avoid cases where 'expr' has been unaliased.

llvm-svn: 116780

now goes into a timestamp-specific directory instead of the previous .session-*
files.

[17:24:34] johnny:/Volumes/data/lldb/svn/trunk $ ls -l test/2010-10-18-16:56:12.935342
total 48
-rw-r--r--  1 johnny  admin  1695 Oct 18 16:56 TestArrayTypes.ArrayTypesTestCase.test_with_dsym_and_run_command.log
-rw-r--r--  1 johnny  admin  1652 Oct 18 16:56 TestArrayTypes.ArrayTypesTestCase.test_with_dwarf_and_run_command.log
-rw-r--r--  1 johnny  admin  2967 Oct 18 16:56 TestBreakpointCommand.BreakpointCommandTestCase.test_with_dsym.log
-rw-r--r--  1 johnny  admin  1648 Oct 18 16:56 TestClassTypes.ClassTypesTestCase.test_with_dwarf_and_run_command.log
-rw-r--r--  1 johnny  admin  1665 Oct 18 16:56 TestClassTypesDisassembly.IterateFrameAndDisassembleTestCase.test_with_dsym_and_python_api.log
-rw-r--r--  1 johnny  admin  3873 Oct 18 16:58 TestFloatTypesExpr.FloatTypesTestCase.test_float_types_with_dsym.log
[17:24:37] johnny:/Volumes/data/lldb/svn/trunk $ 

Also, the dumping happens when a test errored in additioned to when it failed.

llvm-svn: 116778

llvm-svn: 116775

llvm-svn: 116763

llvm-svn: 116748

Also add a more useful assert message for test_set_output_path(), which is currently decorated
with @expectedFailure.

llvm-svn: 116718

Also change the utility functions in lldbutil.py, too, to correspond to the StateType representation change.

llvm-svn: 116706

llvm-svn: 116705

facilitate session recording.  This happens inside an instance method where the
test instance is well known.

llvm-svn: 116649

pass in a 'sender' arg to the buildDefault(), buildDsym(), buildDwarf(), and
cleanup() functions.  The sender arg will be the test instance itself (i.e.,
an instance of TestBase).  This is so that the relevant command execution can be
recorded in the TestBase.session object if sender is available.

The lldbtest.system() command has been modified to pop the 'sender' arg out of
the keyword arguments dictionary and use it as the test instance to facilitate
seesion recordings.  An example is in test/types/AbstractBase.py:

    def generic_type_tester(self, atoms, quotedDisplay=False):
        """Test that variables with basic types are displayed correctly."""

        # First, capture the golden output emitted by the oracle, i.e., the
        # series of printf statements.
        go = system("./a.out", sender=self)

There are cases when sender is None.  This is the case when the @classmethod is
involved in the use of these APIs.  When this happens, there is no recording
into a session object, but printing on the sys.stderr is still honored if the
trace flag is ON.

An example is in test/settings/TestSettings.py:

    @classmethod
    def classCleanup(cls):
        system(["/bin/sh", "-c", "rm -f output.txt"])
        system(["/bin/sh", "-c", "rm -f stdout.txt"])

llvm-svn: 116648

instead of using hard-coded line number.

llvm-svn: 116646

Also change the expected matching pattern of the 'expr -o -- my' output.

llvm-svn: 116645

llvm-svn: 116643

llvm-svn: 116621

'breakpoint delete 1' from 'breakpoint delete'.  With 'breakpoint delete', the
command interpreter was asking for a confirmation from the user, which there
isn't any.

llvm-svn: 116610

    # rdar://problem/8557478
    # test/class_types test failures: runCmd: expr this->m_c_int

llvm-svn: 116609

    breakpoint modify -c 'val == 3' 1

after:

    breakpoint set -n c

which sets a breakpoint on function 'c'.  The breakpoint should only stop if
expression 'val == 3' evaluates to true.

llvm-svn: 116607

the session recordings.

llvm-svn: 116596

llvm-svn: 116583

is no need to check the return status of the command execution, and an error
status is not deemed a failure in the test.

llvm-svn: 116582

llvm-svn: 116559

session info after a test case failure, allowing more direct inspection of
debugger session which leads to the test failure.

For a simple usage scenario:

[18:06:26] johnny:/Volumes/data/lldb/svn/trunk/test $ ./dotest.py -v . 2> ~/Developer/Log/lldbtest.log 

...

[18:14:43] johnny:/Volumes/data/lldb/svn/trunk/test $ ls -l .session-*
-rw-r--r--  1 johnny  admin  1359 Oct 14 18:06 .session-TestArrayTypes.ArrayTypesTestCase.test_with_dwarf_and_run_command
-rw-r--r--  1 johnny  admin  2054 Oct 14 18:07 .session-TestClassTypes.ClassTypesTestCase.test_with_dsym_and_expr_parser
-rw-r--r--  1 johnny  admin  2055 Oct 14 18:07 .session-TestClassTypes.ClassTypesTestCase.test_with_dwarf_and_expr_parser
-rw-r--r--  1 johnny  admin  1351 Oct 14 17:57 .session-TestClassTypes.ClassTypesTestCase.test_with_dwarf_and_run_command
[18:14:51] johnny:/Volumes/data/lldb/svn/trunk/test $ 

The test case which failed will have its recorded session info dumped to a
.session-* file in the current working directory.  For test suite using
relocated directory, expect to find the .session-* files there.

In this checkin, I also add @skip decorator to the two test methods in
test/foundation/TestObjCMethods.py as it looks like the test suite is
deadlocking when running the tests.  More investigations are needed.

llvm-svn: 116552

debug information and you evaluated an expression, a crash would occur as a
result of an unchecked pointer.

Added the ability to get the expression path for a ValueObject. For a rectangle
point child "x" the expression path would be something like: "rect.top_left.x".
This will allow GUI and command lines to get ahold of the expression path for
a value object without having to explicitly know about the hierarchy. This
means the ValueObject base class now has a "ValueObject *m_parent;" member.
All ValueObject subclasses now correctly track their lineage and are able
to provide value expression paths as well.

Added a new "--flat" option to the "frame variable" to allow for flat variable
output. An example of the current and new outputs:

(lldb) frame variable 
argc = 1
argv = 0x00007fff5fbffe80
pt = {
  x = 2
  y = 3
}
rect = {
  bottom_left = {
    x = 1
    y = 2
  }
  top_right = {
    x = 3
    y = 4
  }
}
(lldb) frame variable --flat 
argc = 1
argv = 0x00007fff5fbffe80
pt.x = 2
pt.y = 3
rect.bottom_left.x = 1
rect.bottom_left.y = 2
rect.top_right.x = 3
rect.top_right.y = 4


As you can see when there is a lot of hierarchy it can help flatten things out.
Also if you want to use a member in an expression, you can copy the text from
the "--flat" output and not have to piece it together manually. This can help
when you want to use parts of the STL in expressions:

(lldb) frame variable --flat
argc = 1
argv = 0x00007fff5fbffea8
hello_world._M_dataplus._M_p = 0x0000000000000000
(lldb) expr hello_world._M_dataplus._M_p[0] == '\0'

llvm-svn: 116532

llvm-svn: 116490

Inside the lldb module, there's no need (and as a matter of fact, incorrect) to specify the 'lldb'
module name.

Comment out the call to lldb.SBDebugger.Initialize() within the test driver itself, since it is
already done when we import the lldb.py module.

llvm-svn: 116485

sending it a signal.

llvm-svn: 116481

and 'process handle'.  The test suite would like to control the asynch/sync
execution of the interpreter during the middle of the test method, so the
CommandInterpreter::SetSynchronous(bool value) is modified to allow the mode to
be changed more than once.

In practice, it would be advisable to control the process and to set the
async/sync mode from a single thread, too.

llvm-svn: 116467

llvm-svn: 116420