interface (.i) files for each class.

Changed the FindFunction class from:

uint32_t
SBTarget::FindFunctions (const char *name, 
                         uint32_t name_type_mask, 
                         bool append, 
                         lldb::SBSymbolContextList& sc_list)

uint32_t
SBModule::FindFunctions (const char *name, 
                         uint32_t name_type_mask, 
                         bool append, 
                         lldb::SBSymbolContextList& sc_list)

To:

lldb::SBSymbolContextList
SBTarget::FindFunctions (const char *name, 
                         uint32_t name_type_mask = lldb::eFunctionNameTypeAny);

lldb::SBSymbolContextList
SBModule::FindFunctions (const char *name,
                         uint32_t name_type_mask = lldb::eFunctionNameTypeAny);

This makes the API easier to use from python. Also added the ability to
append a SBSymbolContext or a SBSymbolContextList to a SBSymbolContextList.

Exposed properties for lldb.SBSymbolContextList in python:

lldb.SBSymbolContextList.modules => list() or all lldb.SBModule objects in the list
lldb.SBSymbolContextList.compile_units => list() or all lldb.SBCompileUnits objects in the list
lldb.SBSymbolContextList.functions => list() or all lldb.SBFunction objects in the list
lldb.SBSymbolContextList.blocks => list() or all lldb.SBBlock objects in the list
lldb.SBSymbolContextList.line_entries => list() or all lldb.SBLineEntry objects in the list
lldb.SBSymbolContextList.symbols => list() or all lldb.SBSymbol objects in the list

This allows a call to the SBTarget::FindFunctions(...) and SBModule::FindFunctions(...)
and then the result can be used to extract the desired information:

sc_list = lldb.target.FindFunctions("erase")

for function in sc_list.functions:
    print function
for symbol in sc_list.symbols:
    print symbol

Exposed properties for the lldb.SBSymbolContext objects in python:

lldb.SBSymbolContext.module => lldb.SBModule
lldb.SBSymbolContext.compile_unit => lldb.SBCompileUnit
lldb.SBSymbolContext.function => lldb.SBFunction
lldb.SBSymbolContext.block => lldb.SBBlock
lldb.SBSymbolContext.line_entry => lldb.SBLineEntry
lldb.SBSymbolContext.symbol => lldb.SBSymbol


Exposed properties for the lldb.SBBlock objects in python:

lldb.SBBlock.parent => lldb.SBBlock for the parent block that contains
lldb.SBBlock.sibling => lldb.SBBlock for the sibling block to the current block
lldb.SBBlock.first_child => lldb.SBBlock for the first child block to the current block
lldb.SBBlock.call_site => for inline functions, return a lldb.declaration object that gives the call site file, line and column
lldb.SBBlock.name => for inline functions this is the name of the inline function that this block represents
lldb.SBBlock.inlined_block => returns the inlined function block that contains this block (might return itself if the current block is an inlined block)
lldb.SBBlock.range[int] => access the address ranges for a block by index, a list() with start and end address is returned
lldb.SBBlock.ranges => an array or all address ranges for this block
lldb.SBBlock.num_ranges => the number of address ranges for this blcok

SBFunction objects can now get the SBType and the SBBlock that represents the
top scope of the function.

SBBlock objects can now get the variable list from the current block. The value
list returned allows varaibles to be viewed prior with no process if code
wants to check the variables in a function. There are two ways to get a variable
list from a SBBlock:

lldb::SBValueList
SBBlock::GetVariables (lldb::SBFrame& frame,
                       bool arguments,
                       bool locals,
                       bool statics,
                       lldb::DynamicValueType use_dynamic);

lldb::SBValueList
SBBlock::GetVariables (lldb::SBTarget& target,
                       bool arguments,
                       bool locals,
                       bool statics);

When a SBFrame is used, the values returned will be locked down to the frame
and the values will be evaluated in the context of that frame.

When a SBTarget is used, global an static variables can be viewed without a
running process.

llvm-svn: 149853

llvm-svn: 149852

llvm-svn: 149851

llvm-svn: 149850

llvm-svn: 149849

llvm-svn: 149848

 * Most of the transforms come through intact by having each transformed load or
store copy the ordering and synchronization scope of the original.
 * The transform that turns a global only accessed in main() into an alloca
(since main is non-recursive) with a store of the initial value uses an
unordered store, since it's guaranteed to be the first thing to happen in main.
(Threads may have started before main (!) but they can't have the address of a
function local before the point in the entry block we insert our code.)
 * The heap-SRoA transforms are disabled in the face of atomic operations. This
can probably be improved; it seems odd to have atomic accesses to an alloca
that doesn't have its address taken.

AnalyzeGlobal keeps track of the strongest ordering found in any use of the
global. This is more information than we need right now, but it's cheap to
compute and likely to be useful.

llvm-svn: 149847

llvm-svn: 149846

llvm-svn: 149845

llvm-svn: 149844

predecessor then it's Src.

llvm-svn: 149843

llvm-svn: 149842

above.

llvm-svn: 149841

by GCC).

llvm-svn: 149840

llvm-svn: 149839

logic by half: isOnlyReachableViaThisEdge was trying to be clever and
handle the case of a branch to a basic block which is contained in a
loop.  This costs a domtree lookup and is completely useless due to
GVN's position in the pass pipeline: all loops have preheaders at this
point, which means it is enough for isOnlyReachableViaThisEdge to check
that Dst has only one predecessor.  (I checked this theoretical argument
by running over the entire nightly testsuite, and indeed it is so!).

llvm-svn: 149838

compiling sqlite3, by only doing dom queries after the cheap check
rather than interleaved with it.

llvm-svn: 149836

llvm-svn: 149834

llvm-svn: 149833

llvm-svn: 149832

Names that have corresponding classes in python are commonly started with an
uppercase letter. Let's follow that convention.

llvm-svn: 149831

Contributed by: Gregory Szorc <gregory.szorc@gmail.com>

llvm-svn: 149830

Contributed by: Gregory Szorc <gregory.szorc@gmail.com>

llvm-svn: 149829

Added a missing enumeration.

Contributed by: Gregory Szorc <gregory.szorc@gmail.com>

llvm-svn: 149828

Contributed by: Gregory Szorc <gregory.szorc@gmail.com>

llvm-svn: 149827

Contributed by: Gregory Szorc <gregory.szorc@gmail.com>

llvm-svn: 149826

Contributed by: Gregory Szorc <gregory.szorc@gmail.com>

llvm-svn: 149825

There is no type checking in __eq__, so ctypes will throw if the wrong
Python type is passed in to the C function. Personally, I feel garbage
in means garbage out and it isn't worth testing for this explicitly.

Contributed by: Gregory Szorc <gregory.szorc@gmail.com>

llvm-svn: 149824

llvm-svn: 149823

Patch by Afriza N. Arief!

llvm-svn: 149822

Should bring arm and ppc testers back to life (they default to -mcpu=generic)

llvm-svn: 149821

llvm-svn: 149820

Move operator overload out of line. Calling operator<< on a forward declared type doesn't seem to work on MSVC.

llvm-svn: 149819

llvm-svn: 149817

llvm-svn: 149816

convert at least one client over to use them. Subsequent patches both to
LLVM and Clang will try to convert more people over to a common set of
predicates.

This round of predicates is focused on OS-categorization predicates.

llvm-svn: 149815

llvm-svn: 149814

llvm-svn: 149813

for types and comparing decl context matches.

llvm-svn: 149812

in the DWARF plug-in.

llvm-svn: 149811