llvm-svn: 129707

llvm-svn: 129706

threads, and stack frame down in the lldb_private::Process,
lldb_private::Thread, lldb_private::StackFrameList and the 
lldb_private::StackFrame classes. We had some command line
commands that had duplicate versions of the process status
output ("thread list" and "process status" for example). 

Removed the "file" command and placed it where it should
have been: "target create". Made an alias for "file" to
"target create" so we stay compatible with GDB commands.

We can now have multple usable targets in lldb at the
same time. This is nice for comparing two runs of a program
or debugging more than one binary at the same time. The
new command is "target select <target-idx>" and also to see
a list of the current targets you can use the new "target list"
command. The flow in a debug session can be:

(lldb) target create /path/to/exe/a.out
(lldb) breakpoint set --name main
(lldb) run
... hit breakpoint
(lldb) target create /bin/ls
(lldb) run /tmp
Process 36001 exited with status = 0 (0x00000000) 
(lldb) target list
Current targets:
  target #0: /tmp/args/a.out ( arch=x86_64-apple-darwin, platform=localhost, pid=35999, state=stopped )
* target #1: /bin/ls ( arch=x86_64-apple-darwin, platform=localhost, pid=36001, state=exited )
(lldb) target select 0
Current targets:
* target #0: /tmp/args/a.out ( arch=x86_64-apple-darwin, platform=localhost, pid=35999, state=stopped )
  target #1: /bin/ls ( arch=x86_64-apple-darwin, platform=localhost, pid=36001, state=exited )
(lldb) bt
* thread #1: tid = 0x2d03, 0x0000000100000b9a a.out`main + 42 at main.c:16, stop reason = breakpoint 1.1
  frame #0: 0x0000000100000b9a a.out`main + 42 at main.c:16
  frame #1: 0x0000000100000b64 a.out`start + 52

Above we created a target for "a.out" and ran and hit a
breakpoint at "main". Then we created a new target for /bin/ls
and ran it. Then we listed the targest and selected our original
"a.out" program, so we showed two concurent debug sessions
going on at the same time.

llvm-svn: 129695

Add support for "dynamic values" for C++ classes.  This currently only works for "frame var" and for the
expressions that are simple enough to get passed to the "frame var" underpinnings.  The parser code will
have to be changed to also query for the dynamic types & offsets as it is looking up variables.

The behavior of "frame var" is controlled in two ways.  You can pass "-d {true/false} to the frame var
command to get the dynamic or static value of the variables you are printing.

There's also a general setting:

target.prefer-dynamic-value (boolean) = 'true'

which is consulted if you call "frame var" without supplying a value for the -d option.

llvm-svn: 129623

llvm-svn: 129574

llvm-svn: 129543

llvm-svn: 129542

llvm-svn: 129470

the CommandInterpreter where it was always being used.

Make sure that Modules can track their object file offsets correctly to
allow opening of sub object files (like the "__commpage" on darwin).

Modified the Platforms to be able to launch processes. The first part of this
move is the platform soon will become the entity that launches your program
and when it does, it uses a new ProcessLaunchInfo class which encapsulates
all process launching settings. This simplifies the internal APIs needed for
launching. I want to slowly phase out process launching from the process
classes, so for now we can still launch just as we used to, but eventually
the platform is the object that should do the launching.

Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able
to launch processes with all of the new eLaunchFlag settings. Modified any
code that was manually launching processes to use the Host::LaunchProcess
functions.

Fixed an issue where lldb_private::Args had implicitly defined copy 
constructors that could do the wrong thing. This has now been fixed by adding
an appropriate copy constructor and assignment operator.

Make sure we don't add empty ModuleSP entries to a module list.

Fixed the commpage module creation on MacOSX, but we still need to train
the MacOSX dynamic loader to not get rid of it when it doesn't have an entry
in the all image infos.

Abstracted many more calls from in ProcessGDBRemote down into the 
GDBRemoteCommunicationClient subclass to make the classes cleaner and more
efficient.

Fixed the default iOS ARM register context to be correct and also added support
for targets that don't support the qThreadStopInfo packet by selecting the
current thread (only if needed) and then sending a stop reply packet.

Debugserver can now start up with a --unix-socket (-u for short) and can 
then bind to port zero and send the port it bound to to a listening process
on the other end. This allows the GDB remote platform to spawn new GDB server
instances (debugserver) to allow platform debugging.

llvm-svn: 129351

llvm-svn: 128697

  lldb::SymbolType SBSymbol::GetType();

  lldb::SectionType SBAddress::GetSectionType ();
  lldb::SBModule SBAddress::GetModule ();

Also add an lldb::SBModule::GetUUIDString() API which is easier for Python
to work with in the test script.

llvm-svn: 128695

llvm-svn: 128685

Modify self.expect() patterns to react to API change for SourceManager.DisplaySourceLinesWithLineNumbers().

llvm-svn: 128581

Add a missing result.SetStatus() stmt to the CommandObjectPlatformList::Execute() impl.

llvm-svn: 128575

llvm-svn: 128558

llvm-svn: 128505

an architecture into ArchSpec:

uint32_t
ArchSpec::GetMinimumOpcodeByteSize() const;

uint32_t
ArchSpec::GetMaximumOpcodeByteSize() const;

Added an AddressClass to the Instruction class in Disassembler.h.
This allows decoded instructions to know know if they are code,
code with alternate ISA (thumb), or even data which can be mixed
into code. The instruction does have an address, but it is a good
idea to cache this value so we don't have to look it up more than 
once.

Fixed an issue in Opcode::SetOpcodeBytes() where the length wasn't
getting set.

Changed:

	bool
	SymbolContextList::AppendIfUnique (const SymbolContext& sc);

To:
	bool
	SymbolContextList::AppendIfUnique (const SymbolContext& sc, 
									   bool merge_symbol_into_function);

This function was typically being used when looking up functions
and symbols. Now if you lookup a function, then find the symbol,
they can be merged into the same symbol context and not cause
multiple symbol contexts to appear in a symbol context list that
describes the same function.

Fixed the SymbolContext not equal operator which was causing mixed
mode disassembly to not work ("disassembler --mixed --name main").

Modified the disassembler classes to know about the fact we know,
for a given architecture, what the min and max opcode byte sizes
are. The InstructionList class was modified to return the max
opcode byte size for all of the instructions in its list.
These two fixes means when disassemble a list of instructions and dump 
them and show the opcode bytes, we can format the output more 
intelligently when showing opcode bytes. This affects any architectures
that have varying opcode byte sizes (x86_64 and i386). Knowing the max
opcode byte size also helps us to be able to disassemble N instructions
without having to re-read data if we didn't read enough bytes.

Added the ability to set the architecture for the disassemble command.
This means you can easily cross disassemble data for any supported 
architecture. I also added the ability to specify "thumb" as an 
architecture so that we can force disassembly into thumb mode when
needed. In GDB this was done using a hack of specifying an odd
address when disassembling. I don't want to repeat this hack in LLDB,
so the auto detection between ARM and thumb is failing, just specify
thumb when disassembling:

(lldb) disassemble --arch thumb --name main

You can also have data in say an x86_64 file executable and disassemble
data as any other supported architecture:
% lldb a.out
Current executable set to 'a.out' (x86_64).
(lldb) b main
(lldb) run
(lldb) disassemble --arch thumb --count 2 --start-address 0x0000000100001080 --bytes
0x100001080:  0xb580 push   {r7, lr}
0x100001082:  0xaf00 add    r7, sp, #0

Fixed Target::ReadMemory(...) to be able to deal with Address argument object
that isn't section offset. When an address object was supplied that was
out on the heap or stack, target read memory would fail. Disassembly uses
Target::ReadMemory(...), and the example above where we disassembler thumb
opcodes in an x86 binary was failing do to this bug.

llvm-svn: 128347

    rdar://problem/9173060 lldb hangs while running unique-types

disappears if running with clang version >= 3.  Modify the TestUniqueTypes.py
to detect if we are running with clang version < 3 and, if true, skip the test.

Update the lldbtest.system() function to return a tuple of (stdoutdata, stderrdata)
since we need the stderr data from "clang -v" command.  Modify existing clients of
lldbtest.system() to now use, for example:

         # First, capture the golden output emitted by the oracle, i.e., the
         # series of printf statements.
-        go = system("./a.out", sender=self)
+        go = system("./a.out", sender=self)[0]
         # This golden list contains a list of (variable, value) pairs extracted
         # from the golden output.
         gl = []

And add two utility functions to lldbutil.py.

llvm-svn: 128162

    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