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

not 'frame variable var'.

llvm-svn: 116419

for test_with_dwarf_and_run_command(self).

llvm-svn: 116416

artifical members (like the vtable pointer member that shows up in the DWARF).
We were adding this to each class which was making all member variables be off
by a pointer size.

Added a test case so we can track this with "test/forward".

Fixed the type name index in DWARF to include all the types after finding
some types were being omitted due to the DW_AT_specification having the
DW_AT_declaration attribute which was being read into the real type instances
when there were forward declarations in the DWARF, causing the type to be
omitted. We now check to make sure any DW_AT_declaration values are only
respected when parsing types if the attribute is from the current DIE.

After fixing the missing types, we ran into some issues with the expression
parser finding duplicate entries for __va_list_tag since they are built in
types and would result in a "duplicate __va_list_tag definition" error. We
are now just ignoring this name during lookup, but we will need to see if
we can get the name lookup function to not get called in these cases.

Fixed an issue that would cause an assertion where DW_TAG_subroutine_types
that had no children, would not properly make a clang function type of:
"void (*) (void)".

llvm-svn: 116392

function to get the line numbers for breakpoints 1-5 during setUp().

Use a pattern to match the output from both gcc-compiled and clang-compiled binary.

This finishes the conversion of the test suite to avoid hardcoded line numbers
when setting breakpoints with either the lldb command:

    breakpoint set -f filename -l lineno

or the Python API:

    target.BreakpointCreateByLocation(filename, lineno)

llvm-svn: 116378

function to get the line number to break on during setUp().

Use a pattern to match the output from both gcc-compiled and clang-compiled binary.

llvm-svn: 116374

function to get the line number to break on as well as the line number of the
first executable statement during setUp().

llvm-svn: 116369

function to get the line number to break on during setUp().

llvm-svn: 116363

debug info which results in the breakpoint locations of 3, instead of 1 (as in gcc).

llvm-svn: 116361

function to get the line number to break on during setUp().

llvm-svn: 116358

function to get the line number to break on during setUp().

llvm-svn: 116356

function to get the line number to break on during setUp().

Also modify main.c to use g_file_static_cstr within main() so clang does not
optimize this variable out.

llvm-svn: 116355

function to get the line number to break on during setUp().

llvm-svn: 116352

function to get the line number to break on during setUp().

llvm-svn: 116350

function to get the line number to break on during setUp().

llvm-svn: 116349

function to get the line number to break on during setUp().

llvm-svn: 116346

function to get the line number to break on during setUp().

llvm-svn: 116344

llvm-svn: 116343

different configuration-based files using the config file.  For example:

    sys.stderr = open("/tmp/lldbtest-stderr", "w")
    sys.stdout = open("/tmp/lldbtest-stdout", "w")
    compilers = ["gcc", "llvm-gcc"]
    archs = ["x86_64", "i386"]
    split_stderr = True # This will split the stderr into configuration-specific file
    split_stdout = True # This will split the stdout into configuration-specific file

will produce:

/tmp/lldbtest-stderr
/tmp/lldbtest-stderr.arch=i386-compiler=gcc
/tmp/lldbtest-stderr.arch=i386-compiler=llvm-gcc
/tmp/lldbtest-stderr.arch=x86_64-compiler=gcc
/tmp/lldbtest-stderr.arch=x86_64-compiler=llvm-gcc
/tmp/lldbtest-stdout
/tmp/lldbtest-stdout.arch=i386-compiler=gcc
/tmp/lldbtest-stdout.arch=i386-compiler=llvm-gcc
/tmp/lldbtest-stdout.arch=x86_64-compiler=gcc
/tmp/lldbtest-stdout.arch=x86_64-compiler=llvm-gcc

as a result of splitting stderr and stdout.  In addition, each configuration can have
its individual top level relocated directory to house the test files as well as the
intermediate files by using '-r dir' to relocate the tests into a new relocated directory
instead of running the tests in place.

llvm-svn: 116341

llvm-svn: 116340

    rdar://problem/8542091 test/foundation: expr -o -- my not working?

Add an additional test for 'frame variable *self' when stopped in '-[MyString initWithNSString:]'
and move the 'expr -o -- self' to after MyString has been constructed and change it to
'expr -o -- my'.

llvm-svn: 116337

expanding the regular expression command.  So change the more stringent:

    self.expect(..., startstr = matching_string)

to:

    self.expect(..., substrs = [matched_string])

to pass the test.

llvm-svn: 116331

llvm-svn: 116309

function to get the line number to break on during setUp().

llvm-svn: 116275

within a file.  This is to be used within the test case to avoid hardcoded line number.

array_types/TestArrayTypes.py is modified first to use this pattern.  Other test modules
to follow.

rdar://problem/8537816
Testsuite: don't set breakpoints by exact file & line number

llvm-svn: 116270

files to a different top level directory than those specified on the command line.

When relocated, the test clanups normally performed afterwards after each test method
and after each test class will not be exercised at all.  This allows for an easier
postmortem analysis of test failures.

Example:

./dotest.py -v -t -r /tmp/lldbtest types

will create a /tmp/lldbtest directory which houses the types directory and its supported
files.

Files modified:

o dotest.py, lldbtest.py:

  Add logic to process '-r dir' option to support relocating the tests to a different
  top level directory instead of exected in place.

o darwin.py, test/types/Makefile:

  The 'make clean' should only clean the minimum .o and .d files.

llvm-svn: 116255

llvm-svn: 116206

Added frame relative frame selection to "frame select". You can now select
frames relative to the current frame (which defaults to zero if the current
frame hasn't yet been set for a thread):

The gdb "up" command can be done as:
(lldb) frame select -r 1
The gdb "down" command can be done as:
(lldb) frame select -r -1

Place the following in your ~/.lldbinit file for "up" and "down":

command alias up frame select -r 1
command alias down frame select -r -1

llvm-svn: 116176

with the function name 'lldb_iter'.  Example:

def disassemble_instructions (insts):
    from lldbutil import lldb_iter
    for i in lldb_iter(insts, 'GetSize', 'GetInstructionAtIndex'):
        print i

llvm-svn: 116171

structures into an iterable Python object.

Example:

    def disassemble_instructions (insts):
        from lldbutil import Iterator
        for i in Iterator(insts, 'GetSize', 'GetInstructionAtIndex'):
            print i

llvm-svn: 116137

llvm-svn: 116117

usage to self.expect() which is more descriptive.

llvm-svn: 116115

which is more descriptive.  And wrap the file open operation inside a with block
so that close() is automatically called upon exiting the block.

llvm-svn: 116096

  Update the expected match string.

o lldbtest.py:

  Indicate when a command fails, even if there is nothing in the error stream.

o TestHelp.py:

  Add a regression test case for 'help image dump symtab'.

o CommandObjectHelp.cpp:

  Some of the logic branches with successful help command results were not tagged
  with a Success Status.  They are fixed now.  This is important for Python
  interaction.

llvm-svn: 116062

be removed does not exist for any reason.

llvm-svn: 116025