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

llvm-svn: 126517

llvm-svn: 126516

llvm-svn: 126515

related to 'process launch' command.

llvm-svn: 126514

of Stephen Wilson's idea (thanks for the input Stephen!). What I ended up
doing was:
- Got rid of ArchSpec::CPU (which was a generic CPU enumeration that mimics
  the contents of llvm::Triple::ArchType). We now rely upon the llvm::Triple 
  to give us the machine type from llvm::Triple::ArchType.
- There is a new ArchSpec::Core definition which further qualifies the CPU
  core we are dealing with into a single enumeration. If you need support for
  a new Core and want to debug it in LLDB, it must be added to this list. In
  the future we can allow for dynamic core registration, but for now it is
  hard coded.
- The ArchSpec can now be initialized with a llvm::Triple or with a C string
  that represents the triple (it can just be an arch still like "i386").
- The ArchSpec can still initialize itself with a architecture type -- mach-o
  with cpu type and subtype, or ELF with e_machine + e_flags -- and this will
  then get translated into the internal llvm::Triple::ArchSpec + ArchSpec::Core.
  The mach-o cpu type and subtype can be accessed using the getter functions:
  
  uint32_t
  ArchSpec::GetMachOCPUType () const;

  uint32_t
  ArchSpec::GetMachOCPUSubType () const;
  
  But these functions are just converting out internal llvm::Triple::ArchSpec 
  + ArchSpec::Core back into mach-o. Same goes for ELF.

All code has been updated to deal with the changes.

This should abstract us until later when the llvm::TargetSpec stuff gets
finalized and we can then adopt it.

llvm-svn: 126278

llvm-svn: 126260

llvm-svn: 126257

a Stream, and then added GetOutputData & GetErrorData to get the accumulated data.
- Added a StreamTee that will tee output to two provided lldb::StreamSP's.
- Made the CommandObjectReturn use this so you can Tee the results immediately to
the debuggers output file, as well as saving up the results to return when the command
is done executing.
- HandleCommands now uses this so that if you have a set of commands that continue the target
you will see the commands come out as they are processed.
- The Driver now uses this to output the command results as you go, which makes the interface
more reactive seeming.

llvm-svn: 126015

llvm-svn: 125682