to spawn an lldb child command.  The test is not "correct" in that the '** Stop Hooks **'
message emitted by the Target implementation is invoked asynchronously and is using a separate:

    CommandReturnObject result;

command return object that what the driver passes to the normal command interpreter loop.
But it can help test our output serialization work.

I need to modify the test case later to maybe only test that "-o 'expr ptr'" option does indeed work.

llvm-svn: 130742

llvm-svn: 130741

llvm-svn: 130740

Fix the compiler in the project (accidentally checked in with wrong
compiler).

llvm-svn: 130738

image list command so we can see the full triple for each target module.

llvm-svn: 130728

This patch captures and serializes all output being written by the
command line driver, including the lldb prompt being output by
editline, the asynchronous process output & error messages, and
asynchronous messages written by target stop-hooks.

As part of this it introduces a new Stream class,
StreamAsynchronousIO.  A StreamAsynchronousIO object is created with a
broadcaster, who will eventually broadcast the stream's data for a
listener to handle, and an event type indicating what type of event
the broadcaster will broadcast.  When the Write method is called on a
StreamAsynchronousIO object, the data is appended to an internal
string.  When the Flush method is called on a StreamAsynchronousIO
object, it broadcasts it's data string and clears the string.

Anything in lldb-core that needs to generate asynchronous output for
the end-user should use the StreamAsynchronousIO objects.

I have also added a new notification type for InputReaders, to let
them know that a asynchronous output has been written. This is to
allow the input readers to, for example, refresh their prompts and
lines, if desired.  I added the case statements to all the input
readers to catch this notification, but I haven't added any code for
handling them yet (except to the IOChannel input reader).

llvm-svn: 130721

Add implementation of '==' and '!=' for SBFileSpec and SBModule.  Modify a test case to take advantage of 'ths_module == that_module'.

llvm-svn: 130709

llvm-svn: 130701

llvm-svn: 130698

interface.

Added a quick way to set the platform though the SBDebugger interface. I will
actually an a SBPlatform support soon, but for now this will do.

ConnectionFileDescriptor can be passed a url formatted as: "fd://<fd>" where
<fd> is a file descriptor in the current process. This is handy if you have
services, deamons, or other tools that can spawn processes and give you a
file handle.

llvm-svn: 130565

emulate instruction classes.

llvm-svn: 130556

llvm-svn: 130533

restored after parsing "SBTarget".  Indentation matters in Python. :-)

llvm-svn: 130532

the breakpoint ID and provides the semantics needed for '==' and '!='.  And
modify LLDBIteratorTestCase.lldb_iter_2() to use '==' between two SBBreakpoint's.

llvm-svn: 130531

llvm-svn: 130461

llvm-svn: 130457

llvm-svn: 130456

the lldb iteration protocol has been added to lldb.py module.

llvm-svn: 130452

This is so that the objects which support the iteration protocol are immediately obvious
from looking at the lldb.py file.

SBTarget supports two types of iterations: module and breakpoint.  For an SBTarget instance,
you will need to issue either:

    for m in target.module_iter()

or

    for b in target.breakpoint_iter()

For other single iteration protocol objects, just use, for example:

    for thread in process:
        ID = thread.GetThreadID()
        for frame in thread:
            frame.Disassemble()
            ....

llvm-svn: 130442

depth control, pointer depth, and more) when dumping memory and viewing as
a type.

llvm-svn: 130436

new OptionGroup subclasses for:
- output file for use with options: 
        long opts: --outfile <path> --append--output
        short opts: -o <path> -A
        
- format for use with options:
        long opts: --format <format>

- variable object display controls for depth, pointer depth, wether to show
  types, show summary, show location, flat output, use objc "po" style summary.
  
Modified ValueObjectMemory to be able to be created either with a TypeSP or
a ClangASTType.

Switched "memory read" over to use OptionGroup subclasses: one for the outfile
options, one for the command specific options, and one for the format.

llvm-svn: 130334

method names of all the lldb container objects and returns an iterator object when
passed an eligible lldb container object.

Example:

    from lldb_util import smart_iter
    for thread in smart_iter(process):
        ID = thread.GetThreadID()
        if thread.GetStopReason() == lldb.eStopReasonBreakpoint:
            stopped_due_to_breakpoint = True
        for frame in smart_iter(thread):
            self.assertTrue(frame.GetThread().GetThreadID() == ID)
        ...

Add a test case for lldb.smart_iter().

llvm-svn: 130332

llvm-svn: 130325

Add another test case for lldb_iter(), this time using SBTarget to get at its SBBreakpoint containees.

llvm-svn: 130323

llvm-svn: 130319

And modify the test cases accordingly.

llvm-svn: 130314

for lldb objects which can contain other lldb objects.  Examples are:
SBTarget contains SBModule, SBModule contains SBSymbols, SBProcess contains
SBThread, SBThread contains SBFrame, etc.

llvm-svn: 130258

Switch the EmulateInstruction to use the standard RegisterInfo structure
that is defined in the lldb private types intead of passing the reg kind and
reg num everywhere. EmulateInstruction subclasses also need to provide
RegisterInfo structs given a reg kind and reg num. This eliminates the need
for the GetRegisterName() virtual function and allows more complete information
to be passed around in the read/write register callbacks. Subclasses should
always provide RegiterInfo structs with the generic register info filled in as
well as at least one kind of register number in the RegisterInfo.kinds[] array.

llvm-svn: 130256

llvm-svn: 130254

llvm-svn: 130253

llvm-svn: 130252

llvm-svn: 130251

llvm-svn: 130240

Modify EmulateInstructionARM::SetArchitecture() to treat "arm" and "thumb" as wild card architectures
for now, in order to fix the test failure for the 'arm_emulation' directory.
There might be a better way.

llvm-svn: 130227

are defined as enumerations. Current bits include:

        eEmulateInstructionOptionAutoAdvancePC
        eEmulateInstructionOptionIgnoreConditions

Modified the EmulateInstruction class to have a few more pure virtuals that
can help clients understand how many instructions the emulator can handle:

        virtual bool
        SupportsEmulatingIntructionsOfType (InstructionType inst_type) = 0;


Where instruction types are defined as:

//------------------------------------------------------------------
/// Instruction types
//------------------------------------------------------------------    
typedef enum InstructionType
{
    eInstructionTypeAny,                // Support for any instructions at all (at least one)
    eInstructionTypePrologueEpilogue,   // All prologue and epilogue instructons that push and pop register values and modify sp/fp
    eInstructionTypePCModifying,        // Any instruction that modifies the program counter/instruction pointer
    eInstructionTypeAll                 // All instructions of any kind

}  InstructionType;


This allows use to tell what an emulator can do and also allows us to request
these abilities when we are finding the plug-in interface.

Added the ability for an EmulateInstruction class to get the register names
for any registers that are part of the emulation. This helps with being able
to dump and log effectively.

The UnwindAssembly class now stores the architecture it was created with in
case it is needed later in the unwinding process.

Added a function that can tell us DWARF register names for ARM that goes
along with the source/Utility/ARM_DWARF_Registers.h file: 

        source/Utility/ARM_DWARF_Registers.c
        
Took some of plug-ins out of the lldb_private namespace.

llvm-svn: 130189

And modify the test cases accordingly.

llvm-svn: 130174

Add 'lldb_private' namespace where necessary to prevent ambiguity and
resulting infinite loops.

llvm-svn: 130159

llvm-svn: 130158

llvm-svn: 130156

llvm-svn: 130155