[ASan] Rename __asan_preinit to __local_asan_preinit to avoid warnings from the linker which is trying to export all the __asan_* symbols

llvm-svn: 182567

llvm-svn: 182564

Using fwrite and fread was very *very* slow. The resulting code was multiple
times slower than GCC's implementation of gcov. Replace the fwrite/fread system
with an mmap() version.

If the `.gcda' file doesn't exist, we (re)allocate a buffer that we write
into. That gets written to the `.gcda' file in one chunk. If the `.gcda' file
already exists, we simply mmap() the file, modify the mapped data, and use
msync() to write the contents out to disk. It's much easier than implementing
our own buffering scheme, and we don't have to use fwrite's and fread's
buffering.

For those who are numbers-oriented, here are some timings:

GCC Verison
-----------

`.gcda' files don't exist:  23s
`.gcda' files do exist:     14s

LLVM Version (before this change)
---------------------------------

`.gcda' files don't exist:  28s
`.gcda' files do exist:     28s

LLVM Version (with this change)
-------------------------------

`.gcda' files don't exist:  18s
`.gcda' files do exist:      4s

It's a win-win-win-win-lose-win-win scenario!

<rdar://problem/13466086>

llvm-svn: 182563

llvm-svn: 182562

This should bring the valgrind bot back to life.

llvm-svn: 182561

llvm-svn: 182560

These are not needed since we added the $ORIGIN based rpath.

Fixes pr12517.

llvm-svn: 182559

llvm-svn: 182558

[objc-arc] Fixed number of prefixing slashes in some comments in a function from 3 to 2 to match the rest of ObjCARCOpts.

llvm-svn: 182557

llvm-svn: 182556

Updated the comments of APInt.h to match the llvm style guide and be consistent. No functionality change.

llvm-svn: 182555

removed the bitfields.  This should be conforming
C++11, though, cf. C++03 9.6(3):
"
A bit-field shall have integral or enumeration
type (3.9.1).
"

llvm-svn: 182545

specialization with modules enabled. Just don't merge them at all for now;
we'll revisit this when support for template merging is added.

In passing, make Decl::dump() a little safer to use with PCH/modules, by making
it not deserialize any additional declarations. From a debugger you can call
decls_begin() or similar first if you want to dump all child decls.

llvm-svn: 182544

DEBUG_TYPE is already defined at the beginning of this file. We don't
want to have two different debug flags for a single pass.

Reviewers: shankarke

CC: llvm-commits

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

llvm-svn: 182543

API with my 176880 revision.  If a bad Triple is passed in it can also assert.
In this case too it should just return 0 to indicate failure to create the
disassembler.

rdar://13955214

llvm-svn: 182542

 * Treat _Atomic(T) as a literal type if T is a literal type.
 * Evaluate expressions of this type properly.
 * Fix a lurking bug where we built completely bogus ASTs for converting to
   _Atomic types in C++ in some cases, caught by the tests for this change.

llvm-svn: 182541

llvm-svn: 182540

Patch by Matthew Sorrels

llvm-svn: 182539

llvm-svn: 182538

llvm-svn: 182537

llvm-svn: 182536

Adding in parsing and the start of semantic support for __sptr and __uptr pointer type qualifiers.  This patch also fixes the correlated __ptr32 and __ptr64 pointer qualifiers so that they are truly type attributes instead of declaration attributes.

For more information about __sptr and __uptr, see MSDN: http://msdn.microsoft.com/en-us/library/aa983399.aspx

Patch reviewed by Richard Smith.

llvm-svn: 182535

llvm-svn: 182534

llvm-svn: 182533

There were bits & pieces of code lying around that may've given the
impression that debug info metadata supported the possibility that a
subprogram's type could be specified by a non-subroutine type describing
the return type of a void function. This support was incomplete &
unnecessary. Asserts & API have been changed to make the desired usage
more clear.

llvm-svn: 182532

llvm-svn: 182531

Added logging for the OS plug-in python objects in OperatingSystemPython so we can see the python dictionary returned from the plug-in when logging is enabled.

llvm-svn: 182530

Changes after feedback:
Directly use function pointer, just to be safer on 10.8.

llvm-svn: 182529

live as long as they needed to.  This led to
equality tests involving persistent variables
often failing or succeeding when they had no
business doing so.

To do this, I introduced the ability for a
memory allocation to "leak" - that is, to
persist in the process beyond the lifetime of
the expression.  Hand-declared persistent
variables do this now.

<rdar://problem/13956311>

llvm-svn: 182528

llvm-svn: 182527

llvm-svn: 182526

rdar://problem/13359718

llvm-svn: 182524

Collect 'anonymous memory' info, if possible

llvm-svn: 182523

Summary: "W" bit value was not consistent in ContentPermissions enum. It should always be 2.

Reviewers: kledzik

CC: llvm-commits

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

llvm-svn: 182515

llvm-svn: 182514

Fixed ProcessMachCore to be able to locate the main executeable in the core file even if it doesn't start at a core file address range boundary. Prior to this we only checked the first bytes of each range in the core file for mach_kernel or dyld. Now we still do this, but if we don't find the mach_kernel or dyld anywhere, we go through all core file ranges and check every 0x1000 to see if we can find dyld or the mach_kernel.

Now that we can properly detect the mach_kernel at any address, we don't need to call "DynamicLoaderDarwinKernel::SearchForDarwinKernel(Process*)" anymore.

llvm-svn: 182513

Currently the fast-isel table generator recognizes registers, register
classes, and immediates for source pattern operands.  ValueType
operands are not recognized.  This is not a problem for existing
targets with fast-isel support, but will not work for targets like
PowerPC and SPARC that use types in source patterns.

The proposed patch allows ValueType operands and treats them in the
same manner as register classes.  There is no convenient way to map
from a ValueType to a register class, but there's no need to do so.
The table generator already requires that all types in the source
pattern be identical, and we know the register class of the output
operand already.  So we just assign that register class to any
ValueType operands we encounter.

No functional effect on existing targets.  Testing deferred until the
PowerPC target implements fast-isel.

llvm-svn: 182512

Lock the lldb_private::Module mutex while tearing down the module to make sure we don't get clients accessing the contents on a module as it is going away.

llvm-svn: 182511

Using PatLeaf rather than ImmLeaf when defining immediate predicates
prevents simple patterns using those predicates from being recognized
for fast instruction selection.  This patch replaces the immSExt16
PatLeaf predicate with two ImmLeaf predicates, imm32SExt16 and
imm64SExt16, allowing a few more patterns to be recognized (ADDI,
ADDIC, MULLI, ADDI8, and ADDIC8).  Using the new predicates does not
help for LI, LI8, SUBFIC, and SUBFIC8 because these are rejected for
other reasons, but I see no reason to retain the PatLeaf predicate.

No functional change intended, and thus no test cases yet.  This is
preliminary work for enabling fast-isel support for PowerPC.  When
that support is ready, we'll be able to test this function.

llvm-svn: 182510

llvm-svn: 182509