[ASan] Fix lifetime intrinsics handling. Now for each intrinsic we check if it describes one of 'interesting' allocas. Assume that allocas can go through casts and phi-nodes before apperaring as llvm.lifetime arguments

llvm-svn: 171153

llvm-svn: 171061

llvm-svn: 171060

Rename the 'Attributes' class to 'Attribute'. It's going to represent a single attribute in the future.

llvm-svn: 170502

When ASan replaces <alloca instruction> with
<offset into a common large alloca>, it should also patch
llvm.dbg.declare calls and replace debug info descriptors to mark
that we've replaced alloca with a value that stores an address
of the user variable, not the user variable itself.

See PR11818 for more context.

llvm-svn: 169984

[asan] add experimental -asan-realign-stack option (true by default, which does not change the current behavior) 

llvm-svn: 169216

ASan: add initial support for handling llvm.lifetime intrinsics in ASan - emit calls into runtime library that poison memory for local variables when their lifetime is over and unpoison memory when their lifetime begins.

llvm-svn: 169200

llvm-svn: 169143

Sooooo many of these had incorrect or strange main module includes.
I have manually inspected all of these, and fixed the main module
include to be the nearest plausible thing I could find. If you own or
care about any of these source files, I encourage you to take some time
and check that these edits were sensible. I can't have broken anything
(I strictly added headers, and reordered them, never removed), but they
may not be the headers you'd really like to identify as containing the
API being implemented.

Many forward declarations and missing includes were added to a header
files to allow them to parse cleanly when included first. The main
module rule does in fact have its merits. =]

llvm-svn: 169131

llvm-svn: 168995

[ASan] Simplify check added in r168861. Bail out from module pass early if the module is blacklisted.

llvm-svn: 168913

llvm-svn: 168910

[asan/tsan] initialize the asan/tsan callbacks in runOnFunction as opposed to doInitialization. This is required to allow the upcoming changes in PassManager behavior

llvm-svn: 168864

llvm-svn: 168861

[asan] Split AddressSanitizer into two passes (FunctionPass, ModulePass), LLVM part. This requires a clang part which will follow.

llvm-svn: 168781

llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp: Prune AddressSanitizerCreateGlobalRedzonesPass::ID. [-Wunused-variable]

llvm-svn: 168499

[asan] rip off the creation of global redzones from the main AddressSanitizer class into a separate class. The intent is to make it a separate ModulePass in the following commmits

llvm-svn: 168484

llvm-svn: 168368

[asan] don't instrument linker-initialized globals even with external linkage in -asan-initialization-order mode 

llvm-svn: 168367

[asan] make sure that linker-initialized globals (non-extern) are not instrumented even in -asan-initialization-order mode. This time with a test

llvm-svn: 168366

[asan] fix bug 14277 (asan needs to fail with fata error if an __asan interface function is being redefined. Before this fix asan asserts)

llvm-svn: 167529

llvm-svn: 167295

llvm-svn: 167230

r165941: Resubmit the changes to llvm core to update the functions to
         support different pointer sizes on a per address space basis.

Despite this commit log, this change primarily changed stuff outside of
VMCore, and those changes do not carry any tests for correctness (or
even plausibility), and we have consistently found questionable or flat
out incorrect cases in these changes. Most of them are probably correct,
but we need to devise a system that makes it more clear when we have
handled the address space concerns correctly, and ideally each pass that
gets updated would receive an accompanying test case that exercises that
pass specificaly w.r.t. alternate address spaces.

However, from this commit, I have retained the new C API entry points.
Those were an orthogonal change that probably should have been split
apart, but they seem entirely good.

In several places the changes were very obvious cleanups with no actual
multiple address space code added; these I have not reverted when
I spotted them.

In a few other places there were merge conflicts due to a cleaner
solution being implemented later, often not using address spaces at all.
In those cases, I've preserved the new code which isn't address space
dependent.

This is part of my ongoing effort to clean out the partial address space
code which carries high risk and low test coverage, and not likely to be
finished before the 3.2 release looms closer. Duncan and I would both
like to see the above issues addressed before we return to these
changes.

llvm-svn: 167222

llvm-svn: 166278

[asan] make sure asan erases old unused allocas after it created a new one. This became important after the recent move from ModulePass to FunctionPass because no cleanup is happening after asan pass any more. 

llvm-svn: 166267

llvm-svn: 166102

Resubmit the changes to llvm core to update the functions to support different pointer sizes on a per address space basis.

llvm-svn: 165941

[asan] make AddressSanitizer to be a FunctionPass instead of ModulePass. This will simplify chaining other FunctionPasses with asan. Also some minor cleanup 

llvm-svn: 165936

llvm-svn: 165747

Add in the first iteration of support for llvm/clang/lldb to allow variable per address space pointer sizes to be optimized correctly.

llvm-svn: 165726

We use the enums to query whether an Attributes object has that attribute. The
opaque layer is responsible for knowing where that specific attribute is stored.

llvm-svn: 165488

llvm-svn: 165402

The hasFnAttr method has been replaced by querying the Attributes explicitly. No
intended functionality change.

llvm-svn: 164725

The cases where no initialization happens should still be checked for logic flaws.

llvm-svn: 164032

llvm-svn: 163205

llvm-svn: 163199

Most of the code guarded with ANDROIDEABI are not
ARM-specific, and having no relation with arm-eabi.
Thus, it will be more natural to call this
environment "Android" instead of "ANDROIDEABI".

Note: We are not using ANDROID because several projects
are using "-DANDROID" as the conditional compilation
flag.

llvm-svn: 163087

[asan/tsan] rename FunctionBlackList* to BlackList* as this class is not limited to functions any more

llvm-svn: 162566

[asan] add code to detect global initialization fiasco in C/C++. The sub-pass is off by default for now. Patch by Reid Watson. Note: this patch changes the interface between LLVM and compiler-rt parts of asan. The corresponding patch to compiler-rt will follow.

llvm-svn: 162268