| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
| |
inject some code in that will run via the "__mod_init_func" method that
registers the gcov "writeout" function to execute at exit time.
The problem is that the "__mod_term_func" method of specifying d'tors is
deprecated on Darwin. And it can lead to some ambiguities when dealing with
multiple libraries.
<rdar://problem/11110106>
llvm-svn: 157852
|
| |
|
|
| |
llvm-svn: 157683
|
| |
|
|
|
|
|
|
| |
replicating the code for every place it's needed, we instead generate a function
that does that for us. This function is local to the executable, so there
shouldn't be any writing violations.
llvm-svn: 157564
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
are passed in. However, those arguments may be in a write-protected area, as far
as the runtime library is concerned. For instance, the data could be placed into
a 'linkedit' section, which isn't writable. Emit the code from
llvm_gcda_increment_indirect_counter directly into the function instead.
Note: The code for this is ugly, and can lead to bloat. We should look into
simplifying this code instead of having all of these branches.
<rdar://problem/11181370>
llvm-svn: 157505
|
| |
|
|
| |
llvm-svn: 157317
|
| |
|
|
| |
llvm-svn: 155986
|
| |
|
|
| |
llvm-svn: 155701
|
| |
|
|
| |
llvm-svn: 155698
|
| |
|
|
|
|
| |
the compiled source file.
llvm-svn: 155346
|
| |
|
|
| |
llvm-svn: 155341
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
- don't isntrument reads from constant globals.
Saves ~1.5% of instrumented instructions on CPU2006
(counting static instructions, not their execution).
- don't insrument reads from vtable (which is a global constant too).
Saves ~5%.
I did not measure the run-time impact of this,
but it is certainly non-negative.
llvm-svn: 154444
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
a write to the same temp follows in the same BB.
Also add stats printing.
On Spec CPU2006 this optimization saves roughly 4% of instrumented reads
(which is 3% of all instrumented accesses):
Writes : 161216
Reads : 446458
Reads-before-write: 18295
llvm-svn: 154418
|
| |
|
|
|
|
| |
bug (forgot to return true after instrumenting); make sure the tsan tests are run
llvm-svn: 153448
|
| |
|
|
| |
llvm-svn: 153189
|
| |
|
|
|
|
| |
they are currently used only for experiments
llvm-svn: 153040
|
| |
|
|
| |
llvm-svn: 152755
|
| |
|
|
|
|
| |
separate file -- we will need the same functionality in ThreadSanitizer
llvm-svn: 152753
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change replaces getTypeStoreSize with getTypeAllocSize in AddressSanitizer
instrumentation for stack allocations.
One case where old behaviour produced undesired results is an optimization in
InstCombine pass (PromoteCastOfAllocation), which can replace alloca(T) with
alloca(S), where S has the same AllocSize, but a smaller StoreSize. Another
case is memcpy(long double => long double), where ASan will poison bytes 10-15
of a stack-allocated long double (StoreSize 10, AllocSize 16,
sizeof(long double) = 16).
See http://llvm.org/bugs/show_bug.cgi?id=12047 for more context.
llvm-svn: 151887
|
| |
|
|
| |
llvm-svn: 150449
|
| |
|
|
|
|
|
| |
Clang patch (flags) will follow shortly.
The run-time library will also follow, but not immediately.
llvm-svn: 150423
|
| |
|
|
|
|
| |
llvm part
llvm-svn: 150102
|
| |
|
|
| |
llvm-svn: 149967
|
| |
|
|
|
|
|
|
|
| |
but with a critical fix to the SelectionDAG code that optimizes copies
from strings into immediate stores: the previous code was stopping reading
string data at the first nul. Address this by adding a new argument to
llvm::getConstantStringInfo, preserving the behavior before the patch.
llvm-svn: 149800
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
test to fail.
These are:
r149348
r149351
r149352
r149354
r149356
r149357
r149361
r149362
r149364
r149365
llvm-svn: 149470
|
| |
|
|
|
|
| |
ConstantDataArray::getString instead.
llvm-svn: 149365
|
| |
|
|
| |
llvm-svn: 149300
|
| |
|
|
|
|
|
|
| |
http://code.google.com/p/address-sanitizer/issues/detail?id=32)
The redzones emitted by AddressSanitizer for CFString instances confuse the linker and are of little use, so we shouldn't add them.
llvm-svn: 149243
|
| |
|
|
| |
llvm-svn: 149172
|
| |
|
|
| |
llvm-svn: 148846
|
| |
|
|
| |
llvm-svn: 148697
|
| |
|
|
|
|
| |
don't instrument the function at all on x86_32 if it has a large asm blob
llvm-svn: 147953
|
| |
|
|
| |
llvm-svn: 147667
|
| |
|
|
|
|
| |
This improves the readability of global-buffer-overflow reports.
llvm-svn: 146698
|
| |
|
|
|
|
| |
false positive. compiler part.
llvm-svn: 146688
|
| |
|
|
|
|
| |
builds). This should be done in the run-time.
llvm-svn: 146527
|
| |
|
|
|
|
| |
asan issue 17
llvm-svn: 146503
|
| |
|
|
| |
llvm-svn: 146409
|
| |
|
|
| |
llvm-svn: 146379
|
| |
|
|
|
|
| |
malloc chicken-and-egg situation on Android and probably on other flavours of Linux. Patch by eugenis@google.com.
llvm-svn: 146284
|
| |
|
|
| |
llvm-svn: 145880
|
| |
|
|
|
|
| |
call; use report_fatal_error when blacklist file can not be found
llvm-svn: 145611
|
| |
|
|
| |
llvm-svn: 145420
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
gcc, though I thought it was older (my gcc 4.4 has it as a local patch. Whoops!)
This fixes PR10589.
Also add some debugging statements.
Remove GcnoFiles, the mapping from CompilationUnit to raw_ostream. Now that we
start by iterating over each CU and descending into them, there's no need to
maintain a mapping.
llvm-svn: 145208
|
| |
|
|
| |
llvm-svn: 145092
|
| |
|
|
|
|
| |
large chunks of inline assembler
llvm-svn: 144962
|
| |
|
|
|
|
| |
r144933. For some reason this compiles on linux
llvm-svn: 144936
|
| |
|
|
|
|
| |
asan; add a test check that asan does not touch linkonce_odr
llvm-svn: 144933
|
| |
|
|
| |
llvm-svn: 144758
|
| |
|
|
| |
llvm-svn: 144648
|
| |
|
|
| |
llvm-svn: 143634
|