reserved regs and that register allocators need to explicitly check for
them.

llvm-svn: 113593

I am experimenting with putting visibility-default attributes on all struct/classes in libc++.  This checkin decorates only basic_string and vector as an experiment, and for review by those in this audience that might know more about visibilty than I do.  If I get no negative feedback on this procedure I will begin to decorate the entire library in this way.

llvm-svn: 113590

set the debugger_unique_id with the lldb prefix.

llvm-svn: 113589

that the memoperands are properly set after DAG building and general mucking
about.

llvm-svn: 113585

llvm-svn: 113584

llvm-svn: 113582

The Unwind and RegisterContext subclasses still need
to be finished; none of this code is used by lldb at
this point (unless you call into it by hand).

The ObjectFile class now has an UnwindTable object.

The UnwindTable object has a series of FuncUnwinders
objects (Function Unwinders) -- one for each function
in that ObjectFile we've backtraced through during this
debug session.

The FuncUnwinders object has a few different UnwindPlans.
UnwindPlans are a generic way of describing how to find
the canonical address of a given function's stack frame
(the CFA idea from DWARF/eh_frame) and how to restore the
caller frame's register values, if they have been saved
by this function.

UnwindPlans are created from different sources.  One source is the
eh_frame exception handling information generated by the compiler
for unwinding an exception throw.  Another source is an assembly
language inspection class (UnwindAssemblyProfiler, uses the Plugin
architecture) which looks at the instructions in the funciton
prologue and describes the stack movements/register saves that are
done.

Two additional types of UnwindPlans that are worth noting are
the "fast" stack UnwindPlan which is useful for making a first
pass over a thread's stack, determining how many stack frames there
are and retrieving the pc and CFA values for each frame (enough
to create StackFrameIDs).  Only a minimal set of registers is
recovered during a fast stack walk.  

The final UnwindPlan is an architectural default unwind plan.
These are provided by the ArchDefaultUnwindPlan class (which uses
the plugin architecture).  When no symbol/function address range can
be found for a given pc value -- when we have no eh_frame information
and when we don't have a start address so we can't examine the assembly
language instrucitons -- we have to make a best guess about how to 
unwind.  That's when we use the architectural default UnwindPlan.
On x86_64, this would be to assume that rbp is used as a stack pointer
and we can use that to find the caller's frame pointer and pc value.
It's a last-ditch best guess about how to unwind out of a frame.

There are heuristics about when to use one UnwindPlan versues the other --
this will all happen in the still-begin-written UnwindLLDB subclass of
Unwind which runs the UnwindPlans.

llvm-svn: 113581

the call argument is a string literal. Fixes
<rdar://problem/8413477>.

llvm-svn: 113580

only when ENABLE_SHARED=1.

Loadable module for Win32 requires all symbols resolved for linking.

llvm-svn: 113579

Building archive would be executed due to definition of BUILD_ARCHIVE,
even if BUILD_ARCHIVE = "0".

llvm-svn: 113578

llvm-svn: 113577

to use AddrMode4, there was a count of the registers stored in one of the
operands.  I changed that to just count the operands but forgot to adjust for
the size of D registers.  This was noticed by Evan as a performance problem
but it is a potential correctness bug as well, since it is possible that this
could merge a base update with a non-matching immediate.

llvm-svn: 113576

and the user didn't specify a particular directory, search for the file 
using the $PATH environment variable.

llvm-svn: 113575

llvm-svn: 113574

llvm-svn: 113573

llvm-svn: 113572

cleaning up the output of many GetDescription objects that are part of a 
symbol context. This fixes an issue where no ranges were being printed out
for functions, blocks and symbols.

llvm-svn: 113571

take multiple cycles to decode.
For the current if-converter clients (actually only ARM), the instructions that
are predicated on false are not nops. They would still take machine cycles to
decode. Micro-coded instructions such as LDM / STM can potentially take multiple
cycles to decode. If-converter should take treat them as non-micro-coded
simple instructions.

llvm-svn: 113570

llvm-svn: 113569

Added AnalyzerStatsChecker, a path sensitive check that reports visitation statistics about analysis. Running clang with the -analyzer-stats flag will emit warnings containing the information. We can then run a postanalysis script to take this data and give useful information about how much the analyzer missed in a project.

llvm-svn: 113568

llvm-svn: 113566

more clear.  No functional change.

llvm-svn: 113565

address of a label (GNU extension).

llvm-svn: 113564

bad as I'd thought.

llvm-svn: 113561

llvm-svn: 113560

is different from what the code now uses in a two ways: NamedMDNodes
were considered Values and included in the numbering, and the
function-local metadata counter wasn't reset between functions.

The later problem breaks lazy deserialization, so instead of trying
to emulate the old numbering, just drop the old metadata. The only
in-tree use case is debug info with LTO, where the QOI loss is
considered acceptable.

llvm-svn: 113557

and array references).

llvm-svn: 113556

follows objective's semantics and is not overload'able
with an assignment operator. Fixes a crash and a missing
diagnostics. Radar 8379892.

llvm-svn: 113555

Fixes: <rdar://problem/8409480> “warning: Pass-by-value argument in function call is undefined” message can be improved
llvm-svn: 113554

spelled (#pragma, _Pragma, __pragma). In -E mode, use that information
to add appropriate newlines when translating _Pragma and __pragma into
#pragma, like GCC does. Fixes <rdar://problem/8412013>.

llvm-svn: 113553

 - This is annoying, because we have to scatter this check everywhere that could emit real data, but I see no better solution.

llvm-svn: 113552

llvm-svn: 113551

llvm-svn: 113550

llvm-svn: 113549

some data around and implement a couple of move routines to do this.

llvm-svn: 113546

constructor, in source order. Also introduces a new reference kind for
class members, which is used here (for member initializers) and will
also be used for designated initializers and offsetof.

llvm-svn: 113545

llvm-svn: 113542

llvm-svn: 113541

llvm-svn: 113539

regular value references.

llvm-svn: 113538