test suite: lldb hangs while running unique-types

llvm-svn: 128131

Failures were due to new commands introduced.

llvm-svn: 128125

overlap in the SWIG integration which has now been fixed by introducing
callbacks for initializing SWIG for each language (python only right now).
There was also a breakpoint command callback that called into SWIG which has
been abtracted into a callback to avoid cross over as well.

Added a new binary: lldb-platform

This will be the start of the remote platform that will use as much of the 
Host functionality to do its job so it should just work on all platforms.
It is pretty hollowed out for now, but soon it will implement a platform
using the GDB remote packets as the transport.

llvm-svn: 128053

in the same compilation module show up as different types for lldb debugger.

llvm-svn: 127904

which the testsuite is run against.

llvm-svn: 127782

easier since "short" ends up with "short int" in the template allocators.

llvm-svn: 127661

types that have different contents. Currently LLDB is incorrectly uniquing,
on MacOSX, the std::vector _VectorImpl class from the two different vector
templates. The DWARF looks like:

0x0000008e:         DW_TAG_structure_type [7] *
                     DW_AT_name( "_Vector_base<int,std::allocator<int> >" )
                     DW_AT_declaration( 0x01 )
                     DW_AT_sibling( {0x00000103} )

0x00000098:             DW_TAG_structure_type [8] *
                         DW_AT_name( "_Vector_impl" )
                         DW_AT_byte_size( 0x18 )
                         DW_AT_decl_file( "/usr/include/c++/4.2.1/bits/stl_vector.h" )
                         DW_AT_decl_line( 83 )

0x000000a0:                 DW_TAG_inheritance [9]  
                             DW_AT_type( {0x000006fa} ( allocator<int> ) )
                             DW_AT_data_member_location( +0 )
                             DW_AT_accessibility( DW_ACCESS_public )



0x0000011b:         DW_TAG_structure_type [7] *
                     DW_AT_name( "_Vector_base<short int,std::allocator<short int> >" )
                     DW_AT_declaration( 0x01 )
                     DW_AT_sibling( {0x00000190} )

0x00000125:             DW_TAG_structure_type [8] *
                         DW_AT_name( "_Vector_impl" )
                         DW_AT_byte_size( 0x18 )
                         DW_AT_decl_file( "/usr/include/c++/4.2.1/bits/stl_vector.h" )
                         DW_AT_decl_line( 83 )

0x0000012d:                 DW_TAG_inheritance [9]  
                             DW_AT_type( {0x00000f75} ( allocator<short int> ) )
                             DW_AT_data_member_location( +0 )
                             DW_AT_accessibility( DW_ACCESS_public )


In this case it using DIE 0x00000098 for both 0x00000098 and 0x00000125.

This test will help detect this issue once I have a fix for it. I have a fix
that I am testing.

llvm-svn: 127660

This uses pexpect module to spawn a 'lldb' program and uses pseudo-TTY to talk to
the child application.

The test cases test setting breakpoints, adding a stop-hook with line range, and
verifies that when the inferior stops, the stop-hook will fire off when it is
within range and will not fire off when it is out of range.

llvm-svn: 127519

Add pexpect-2.4 (a pure Python module for controlling and automating other programs) to the test directory.

http://pypi.python.org/pypi/pexpect/

llvm-svn: 127484

llvm-svn: 127481

This provides a way to potentially provide conversational interactions with 'lldb' in the test suite.

llvm-svn: 127479

SBTarget.Launch() API, stop at a breakpoint, get the stopped thread, and verify that the
pid of the stopped thread's process is equal to the pid of the process returned by
SBTarget.Launch().

llvm-svn: 127444

The test itself is not working yet.

llvm-svn: 127436

doing three step-over's, then verifying that the correct source line number is reached.

llvm-svn: 127432

Add a test case to make sure that all the settings that currently ought to
exist are actually there.

llvm-svn: 127431

llvm-svn: 127421

Add test cases for Python SBThread.StepOut() API by stepping out of a malloc call where the call site is at function b().
Verifies that after the thread.StepOut(), we are at the correct line within function b.

llvm-svn: 127374

It fails when running within the context of the test suite, but succeeds
when running alone.

llvm-svn: 127290

We should still see the entire stdout redirected once the process is finished.

llvm-svn: 127184

llvm-svn: 127179

Currently it has only test cases for SBThread.GetStopDescription() API.

Also modified lldb.swig to add typemap for (char *dst, size_t dst_len)
which occurs for SBThread::GetStopDescription() C++ API.  For Python
scripting:

    # Due to the typemap magic (see lldb.swig), we pass in an (int)length to GetStopDescription
    # and expect to get a Python string as the result object!
    # The 100 is just an arbitrary number specifying the buffer size.
    stop_description = thread.GetStopDescription(100)

llvm-svn: 127173

API with a process not in eStateConnected, and checks that the remote launch failed.

Modify SBProcess::RemoteLaunch()/RemoteAttachToProcessWithID()'s log statements to fix a
crasher when logging is turned on.

llvm-svn: 127055

We start a fake debugserver listening on localhost:12345 and issue the command
'process connect connect://localhost:12345' to connect to it.

llvm-svn: 127048

llvm-svn: 127025

This allows us to override CFLAGS on the command line:

$ CFLAGS='-arch $(ARCH) -gdwarf-2 -O0' ./dotest.py -C clang -A i386 -v objc-optimized

Session logs for test failures/errors will go into directory '2011-03-04-10_33_57'
Command invoked: python ./dotest.py -C clang -A i386 -v objc-optimized
----------------------------------------------------------------------
Collected 2 tests

1: test_break_with_dsym (TestObjcOptimized.ObjcOptimizedTestCase)
   Test 'expr member' continues to work for optimized build. ... ok
2: test_break_with_dwarf (TestObjcOptimized.ObjcOptimizedTestCase)
   Test 'expr member' continues to work for optimized build. ... ok

----------------------------------------------------------------------
Ran 2 tests in 1.902s

OK
$

llvm-svn: 127011

test that objective-c expression parser continues to work for optimized build.

Radar filed:
# rdar://problem/9087739
# test failure: objc_optimized does not work for "-C clang -A i386"

llvm-svn: 127009

llvm-svn: 126980

on the command line.  For example, use '-A x86_64^i386' to launch the inferior use both x86_64
and i386.

This is an example of building the debuggee using both clang and gcc compiers:

[17:30:46] johnny:/Volumes/data/lldb/svn/trunk/test $ ./dotest.py -C clang^gcc -v -f SourceManagerTestCase.test_modify_source_file_while_debugging

Session logs for test failures/errors will go into directory '2011-03-03-17_31_39'
Command invoked: python ./dotest.py -C clang^gcc -v -f SourceManagerTestCase.test_modify_source_file_while_debugging

Configuration:  compiler=clang
----------------------------------------------------------------------
Collected 1 test

1: test_modify_source_file_while_debugging (TestSourceManager.SourceManagerTestCase)
   Modify a source file while debugging the executable. ... Command 'run' failed!

original content: #include <stdio.h>

int main(int argc, char const *argv[]) {
    printf("Hello world.\n"); // Set break point at this line.
    return 0;
}

new content: #include <stdio.h>

int main(int argc, char const *argv[]) {
    printf("Hello lldb.\n"); // Set break point at this line.
    return 0;
}

os.path.getmtime() after writing new content: 1299202305.0
content restored to: #include <stdio.h>

int main(int argc, char const *argv[]) {
    printf("Hello world.\n"); // Set break point at this line.
    return 0;
}

os.path.getmtime() after restore: 1299202307.0
ok

----------------------------------------------------------------------
Ran 1 test in 8.259s

OK

Configuration:  compiler=gcc
----------------------------------------------------------------------
Collected 1 test

1: test_modify_source_file_while_debugging (TestSourceManager.SourceManagerTestCase)
   Modify a source file while debugging the executable. ... original content: #include <stdio.h>

int main(int argc, char const *argv[]) {
    printf("Hello world.\n"); // Set break point at this line.
    return 0;
}

new content: #include <stdio.h>

int main(int argc, char const *argv[]) {
    printf("Hello lldb.\n"); // Set break point at this line.
    return 0;
}

os.path.getmtime() after writing new content: 1299202307.0
content restored to: #include <stdio.h>

int main(int argc, char const *argv[]) {
    printf("Hello world.\n"); // Set break point at this line.
    return 0;
}

os.path.getmtime() after restore: 1299202309.0
ok

----------------------------------------------------------------------
Ran 1 test in 2.301s

OK
[17:31:49] johnny:/Volumes/data/lldb/svn/trunk/test $ 

llvm-svn: 126979

among other things:

// When stopped on breakppint 1, we can get the line entry using SBFrame API
// SBFrame.GetLineEntry().  We'll get the start address for the the line entry
// with the SBAddress type, resolve the symbol context using the SBTarget API
// SBTarget.ResolveSymbolContextForAddress() in order to get the SBSymbol.
//
// We then stop at breakpoint 2, get the SBFrame, and the the SBFunction object.
//
// The address from calling GetStartAddress() on the symbol and the function
// should point to the same address, and we also verify that.

And add one utility function disassemble(target, function_or_symbol) to lldbutil.py:

    """Disassemble the function or symbol given a target.

    It returns the disassembly content in a string object.
    """

TestDisasm.py uses the disassemble() function to do disassembly on the SBSymbol, and
then the SBFunction object.

llvm-svn: 126955

// When stopped on breakppint 1, and then 2, we can get the line entries using
// SBFrame API SBFrame.GetLineEntry().  We'll get the start addresses for the
// two line entries; with the start address (of SBAddress type), we can then
// resolve the symbol context using the SBTarget API
// SBTarget.ResolveSymbolContextForAddress().
//
// The two symbol context should point to the same symbol, i.e., 'a' function.


Add two utility functions to lldbutil.py:

o get_stopped_threads(process, reason):

  return the list of threads with the specified stop reason or an empty list if not found

o get_stopped_thread(process, reason):

  return the first thread with the given stop reason or None if not found

llvm-svn: 126916

llvm-svn: 126877

llvm-svn: 126867

o int_to_bytearray()
o bytearray_to_int()

They return/interpret the bytearray in the little endian format.
For big endian, simply perform ba.reverse() on the bytearray object.

And modify TestProcessAPI.py to take advantage of the functions.

llvm-svn: 126813

among other SBProcess APIs, to write (int)256 into a memory location of a global variable
(int)my_int and reads/checks the variable afterwards.

llvm-svn: 126792

llvm-svn: 126774

This makes the number of total tests equal to 201.

llvm-svn: 126769

the SBProcess.ReadMemory() API, which, due to SWIG typemap'ing, expects 3 arguments (the location
to read from, the size in bytes to read, and an SBError object), and returns the result as a
Python string object.

On SnowLeopard where this has been tested, the SWIG script needs to be pampered (use the exact
same parameter names as in SBProcess.h) in order for this to work.

llvm-svn: 126736

llvm-svn: 126531

the intermediate files built with the same dictionary during test execution.

llvm-svn: 126530

current working directory when running the inferior.  Radar filed:

    # rdar://problem/9056462
    # The process launch flag '-w' for setting the current working directory not working?

llvm-svn: 126529