Make breakpoint setting by file and line much more efficient by only looking for inlined breakpoint locations if we are setting a breakpoint in anything but a source implementation file. Implementing this complex for a many reasons. Turns out that parsing compile units lazily had some issues with respect to how we need to do things with DWARF in .o files. So the fixes in the checkin for this makes these changes:
- Add a new setting called "target.inline-breakpoint-strategy" which can be set to "never", "always", or "headers". "never" will never try and set any inlined breakpoints (fastest). "always" always looks for inlined breakpoint locations (slowest, but most accurate). "headers", which is the default setting, will only look for inlined breakpoint locations if the breakpoint is set in what are consudered to be header files, which is realy defined as "not in an implementation source file". 
- modify the breakpoint setting by file and line to check the current "target.inline-breakpoint-strategy" setting and act accordingly
- Modify compile units to be able to get their language and other info lazily. This allows us to create compile units from the debug map and not have to fill all of the details in, and then lazily discover this information as we go on debuggging. This is needed to avoid parsing all .o files when setting breakpoints in implementation only files (no inlines). Otherwise we would need to parse the .o file, the object file (mach-o in our case) and the symbol file (DWARF in the object file) just to see what the compile unit was.
- modify the "SymbolFileDWARFDebugMap" to subclass lldb_private::Module so that the virtual "GetObjectFile()" and "GetSymbolVendor()" functions can be intercepted when the .o file contenst are later lazilly needed. Prior to this fix, when we first instantiated the "SymbolFileDWARFDebugMap" class, we would also make modules, object files and symbol files for every .o file in the debug map because we needed to fix up the sections in the .o files with information that is in the executable debug map. Now we lazily do this in the DebugMapModule::GetObjectFile()

Cleaned up header includes a bit as well.

llvm-svn: 162860

This means the same as LoadInst/StoreInst::isUnordered(), and implies
!isVolatile().

Atomic loads and stored are also ordered, and this is the right method
to check if it is safe to reorder memory operations. Ordered atomics
can't be reordered wrt normal loads and stores, which is a stronger
constraint than volatile.

llvm-svn: 162859

The patch suggested by Brad Smith.

llvm-svn: 162858

It is technically allowed to move a normal load across a volatile load,
but probably not a good idea.

It is not allowed to move a load across an atomic load with
Ordering > Monotonic, and we model those with MOVolatile as well.

I recently removed the mayStore flag from atomic load instructions, so
they don't need a pseudo-opcode. This patch makes up for the difference.

llvm-svn: 162857

llvm-svn: 162856

This lets the user run the program from a different directory and still have the
.gcda files show up in the correct place.
<rdar://problem/12179524>

llvm-svn: 162855

We need to reserve space for the mandatory traceback fields,
though leaving them as zero is appropriate for now.

Although the ABI calls for these fields to be filled in fully, no
compiler on Linux currently does this, and GDB does not read these
fields.  GDB uses the first word of zeroes during exception handling to
find the end of the function and the size field, allowing it to compute
the beginning of the function.  DWARF information is used for everything
else.  We need the extra 8 bytes of pad so the size field is found in
the right place.

As a comparison, GCC fills in a few of the fields -- language, number
of saved registers -- but ignores the rest.  IBM's proprietary OSes do
make use of the full traceback table facility.

Patch by Bill Schmidt.

llvm-svn: 162854

to define all macros for MIPS targets. Remove redundant virtual function
getArchDefines(). Two virtual functions for this task are really too much.

llvm-svn: 162853

llvm-svn: 162852

llvm-svn: 162851

CheckLValueConstantExpression.

Richard pointed out that using the address of a TLS variable is ok in a
core C++11 constant expression, as long as it isn't part of the eventual
result of constant expression evaluation. Having the check in
CheckLValueConstantExpression accomplishes this.

llvm-svn: 162850

The operands on an INLINEASM machine instruction are divided into groups
headed by immediate flag operands. Verify this structure.

Extract verifyTiedOperands(), and only call it for non-inlineasm
instructions.

llvm-svn: 162849

llvm-svn: 162848

when assignment expression in conditional invloves
property reference. // rdar://11066598

llvm-svn: 162846

Summary:
The problem was with the following sequence:
  #pragma push_macro("long")
  #undef long
  #pragma pop_macro("long")
in case when "long" didn't represent a macro.
Fixed crash and removed code duplication for #undef/pop_macro case. Added regression tests.

Reviewers: doug.gregor, klimek

Reviewed By: doug.gregor

CC: cfe-commits, chapuni

Differential Revision: http://llvm-reviews.chandlerc.com/D31

llvm-svn: 162845

llvm-svn: 162844

llvm-svn: 162843

[ASan] fix flakiness of Linux-specific clone_test: waitpid should better be provided with __WCLONE option, otherwise it didn't wait for the subprocess, returned -1, and we went crushing the subprocess stack

llvm-svn: 162842

This disables malloc-specific optimization when -fno-builtin (or -ffreestanding)
is specified. This has been a problem for a long time but became more severe
with the recent memory builtin improvements.

Since the memory builtin functions are used everywhere, this required passing
TLI in many places. This means that functions that now have an optional TLI
argument, like RecursivelyDeleteTriviallyDeadFunctions, won't remove dead
mallocs anymore if the TLI argument is missing. I've updated most passes to do
the right thing.

Fixes PR13694 and probably others.

llvm-svn: 162841

The patch suggested by Logan Chien.

llvm-svn: 162840

For invalid pointers passed to free_common check whether they are actually skewed to hold an additional CFAllocatorRef.
If so, fix the pointer and pass it to asan_free.

See http://code.google.com/p/address-sanitizer/issues/detail?id=70 for more background.

llvm-svn: 162839

Reversing the logic since C99 mode is actually not an extension.  Also, changing the group to the singular to match the diagnostic better.

llvm-svn: 162838

VisitVarDecl should return Error(E), and we should test that the address
of a TLS var can't be used as a constexpr.

llvm-svn: 162837

Can't use __thread in init.c because it doesn't have a triple.

llvm-svn: 162836

This makes Clang produce an error for code such as:

  __thread int x;
  int *p = &x;

The lvalue of a thread-local variable cannot be evaluated at compile
time.

llvm-svn: 162835

[asan/tsan] use InternalScopedBuffer instead of stack arrays. Use mmap inseted of InternalAlloc in InternalScopedBuffer

llvm-svn: 162834

[super dealloc].  rdar://problem/11141872

llvm-svn: 162833

[tsan] fix tsan's Makefile.old -- our build bot still uses it (hopefully, will soon migrate to cmake completely)

llvm-svn: 162832

[asan] fix asan's Makefile.old -- our build bot still uses it (hopefully, will soon migrate to cmake completely)

llvm-svn: 162831

llvm-svn: 162830

llvm-svn: 162829

llvm-svn: 162828

a comma separated collection of key:value pairs (which are strings).  This
allows a general way to provide analyzer configuration data from the command line.

No clients yet.

llvm-svn: 162827

llvm-svn: 162826

llvm-svn: 162825

Adding arbitrary records to ARM.td would break
basic-arm-instructions.s because selection of nop vs mov r0,r0 was
ambiguous (this will be tested by a subsequent addition to ARM.td).
An imperfect but sensible fix is to give precedence to match rules
that have more constraints.

llvm-svn: 162824

llvm-svn: 162823

library.

These headers are intended to be available to user code when built with
AddressSanitizer (or one of the other sanitizer's in the future) to
interface with the runtime library. As such, they form stable external
C interfaces, and the headers shouldn't be located within the
implementation.

I've pulled them out into what seem like fairly obvious locations and
names, but I'm wide open to further bikeshedding of these names and
locations.

I've updated the code and the build system to cope with the new
locations, both CMake and Makefile. Please let me know if this breaks
anyone's build.

The eventual goal is to install these headers along side the Clang
builtin headers when we build the ASan runtime and install it. My
current thinking is to locate them at:

  <prefix>/lib/clang/X.Y/include/sanitizer/common_interface_defs.h
  <prefix>/lib/clang/X.Y/include/sanitizer/asan_interface.h
  <prefix>/lib/clang/X.Y/include/sanitizer/...

But maybe others have different suggestions?

Fixing the style of the #include between these headers at least unblocks
experimentation with installing them as they now should work when
installed in these locations.

llvm-svn: 162822

I have tested the fix, but have not been successfull in generating
a robust unit test. This can only be exposed through particular
register assignments.

llvm-svn: 162821

llvm-svn: 162820