| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
On Darwin, section names have a 16char length limit.
llvm-svn: 305429
|
|
|
|
|
|
| |
-fsanitize-coverage=inline-8bit-counters. Experimental so far, not documenting yet. Reapplying revisions 304630, 304631, 304632, 304673, see PR33308
llvm-svn: 305026
|
|
|
|
|
|
|
|
| |
-fsanitize-coverage=inline-8bit-counters. Experimental so far, not documenting yet."
This reverts commit r304630, as it broke ARM/AArch64 bots for 2 days.
llvm-svn: 304698
|
|
|
|
|
|
| |
-fsanitize-coverage=inline-8bit-counters. Experimental so far, not documenting yet.
llvm-svn: 304630
|
|
|
|
|
|
| |
sections in future. NFC
llvm-svn: 304610
|
|
|
|
| |
llvm-svn: 304319
|
|
|
|
|
|
|
|
|
|
|
| |
Coverage instrumentation which does not instrument full post-dominators
and full-dominators may skip valid paths, as the reasoning for skipping
blocks may become circular.
This patch fixes that, by only skipping
full post-dominators with multiple predecessors, as such predecessors by
definition can not be full-dominators.
llvm-svn: 303827
|
|
|
|
|
|
|
| |
This reverts commit 2ed06f05fc10869dd1239cff96fcdea2ee8bf4ef.
Buildbots do not like this on Linux.
llvm-svn: 303710
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Coverage instrumentation has an optimization not to instrument extra
blocks, if the pass is already "accounted for" by a
successor/predecessor basic block.
However (https://github.com/google/sanitizers/issues/783) this
reasoning may become circular, which stops valid paths from having
coverage.
In the worst case this can cause fuzzing to stop working entirely.
This change simplifies logic to something which trivially can not have
such circular reasoning, as losing valid paths does not seem like a
good trade-off for a ~15% decrease in the # of instrumented basic blocks.
llvm-svn: 303698
|
|
|
|
|
|
| |
hidden -mllvm flag. llvm part.
llvm-svn: 302319
|
|
|
|
| |
llvm-svn: 300778
|
|
|
|
| |
llvm-svn: 300777
|
|
|
|
| |
llvm-svn: 300769
|
|
|
|
|
|
|
|
|
|
|
| |
templates.
From a user prospective, it forces the use of an annoying nullptr to mark the end of the vararg, and there's not type checking on the arguments.
The variadic template is an obvious solution to both issues.
Differential Revision: https://reviews.llvm.org/D31070
llvm-svn: 299949
|
|
|
|
|
|
|
| |
This reverts commit r299925 because it broke the buildbots. See e.g.
http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15/builds/6008
llvm-svn: 299928
|
|
|
|
|
|
|
|
|
|
|
|
| |
Module::getOrInsertFunction is using C-style vararg instead of
variadic templates.
From a user prospective, it forces the use of an annoying nullptr
to mark the end of the vararg, and there's not type checking on the
arguments. The variadic template is an obvious solution to both
issues.
llvm-svn: 299925
|
|
|
|
|
|
| |
This reverts commit r299699, the examples needs to be updated.
llvm-svn: 299702
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Module::getOrInsertFunction is using C-style vararg instead of
variadic templates.
From a user prospective, it forces the use of an annoying nullptr
to mark the end of the vararg, and there's not type checking on the
arguments. The variadic template is an obvious solution to both
issues.
Patch by: Serge Guelton <serge.guelton@telecom-bretagne.eu>
Differential Revision: https://reviews.llvm.org/D31070
llvm-svn: 299699
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This prevents crashes when attempting to instrument functions containing
C++ try.
Sanitizer coverage will still fail at runtime when an exception is
thrown through a sancov instrumented function, but that seems marginally
better than what we have now. The full solution is to color the blocks
in LLVM IR and only instrument blocks that have an unambiguous color,
using the appropriate token.
llvm-svn: 298662
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D29733
llvm-svn: 294529
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D29662
llvm-svn: 294517
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On Windows, the symbols "___stop___sancov_guards" and "___start___sancov_guards"
are not defined automatically. So, we need to take a different approach.
We define 3 sections:
Section ".SCOV$A" will only hold a variable ___start___sancov_guard.
Section ".SCOV$M" will hold the main data.
Section ".SCOV$Z" will only hold a variable ___stop___sancov_guards.
When linking, they will be merged sorted by the characters after the $, so we
can use the pointers of the variables ___[start|stop]___sancov_guard to know the
actual range of addresses of that section.
In this diff, I updated instrumentation to include all the guard arrays in
section ".SCOV$M".
Differential Revision: https://reviews.llvm.org/D28434
llvm-svn: 293987
|
|
|
|
|
|
|
| |
MachO's sections need a segment as well as a section name, and the
section start and end symbols are spelled differently than on ELF.
llvm-svn: 293733
|
|
|
|
|
|
| |
'if' by default. Update the docs, also add deprecation notes around other parts of sanitizer coverage
llvm-svn: 292862
|
|
|
|
| |
llvm-svn: 290628
|
|
|
|
| |
llvm-svn: 288568
|
|
|
|
|
|
|
| |
If the global name doesn't start with __sancov_gen, ASan will insert
unecessary red zones around it.
llvm-svn: 287117
|
|
|
|
|
|
| |
(reported in https://github.com/google/oss-fuzz/issues/84)
llvm-svn: 287030
|
|
|
|
|
|
|
|
| |
They get called before initialization, which is a problem for winasan.
Test coming in compiler-rt.
llvm-svn: 286615
|
|
|
|
|
|
| |
commented-out code.
llvm-svn: 283924
|
|
|
|
| |
llvm-svn: 283004
|
|
|
|
|
|
| |
one array of guards per function, instead of one guard per BB. reorganize the code so that trace-pc-guard does not create unneeded globals
llvm-svn: 282735
|
|
|
|
| |
llvm-svn: 282467
|
|
|
|
|
|
| |
instrumented
llvm-svn: 282465
|
|
|
|
| |
llvm-svn: 281952
|
|
|
|
|
|
| |
the guard type to intptr_t; use separate array for 8-bit counters
llvm-svn: 281845
|
|
|
|
| |
llvm-svn: 281809
|
|
|
|
| |
llvm-svn: 281665
|
|
|
|
|
|
| |
trace-pc-guard. The intent is to eventually replace all of {bool coverage, 8bit-counters, trace-pc} with just this one. LLVM part
llvm-svn: 281431
|
|
|
|
|
|
| |
trace-gep, mostly usaful for value-profile-based fuzzing; llvm part
llvm-svn: 280043
|
|
|
|
|
|
| |
__sanitizer_cov_trace_cmp[1248] instead of __sanitizer_cov_trace_cmp, don't pass the comparison type to save a bit performance. Use these new callbacks in libFuzzer
llvm-svn: 279027
|
|
|
|
|
|
| |
not merged (otherwise different calls get the same PC and confuse fuzzers)
llvm-svn: 275449
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D18844
llvm-svn: 265615
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
In the context of http://wg21.link/lwg2445 C++ uses the concept of
'stronger' ordering but doesn't define it properly. This should be fixed
in C++17 barring a small question that's still open.
The code currently plays fast and loose with the AtomicOrdering
enum. Using an enum class is one step towards tightening things. I later
also want to tighten related enums, such as clang's
AtomicOrderingKind (which should be shared with LLVM as a 'C++ ABI'
enum).
This change touches a few lines of code which can be improved later, I'd
like to keep it as NFC for now as it's already quite complex. I have
related changes for clang.
As a follow-up I'll add:
bool operator<(AtomicOrdering, AtomicOrdering) = delete;
bool operator>(AtomicOrdering, AtomicOrdering) = delete;
bool operator<=(AtomicOrdering, AtomicOrdering) = delete;
bool operator>=(AtomicOrdering, AtomicOrdering) = delete;
This is separate so that clang and LLVM changes don't need to be in sync.
Reviewers: jyknight, reames
Subscribers: jyknight, llvm-commits
Differential Revision: http://reviews.llvm.org/D18775
llvm-svn: 265602
|
|
|
|
| |
llvm-svn: 265168
|
|
|
|
|
|
|
|
| |
Summary: Reply to http://reviews.llvm.org/D18341
Differential Revision: http://reviews.llvm.org/D18406
llvm-svn: 264213
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Without tree pruning clang has 2,667,552 points.
Wiht only dominators pruning: 1,515,586.
With both dominators & predominators pruning: 1,340,534.
Resubmit of r262103.
Differential Revision: http://reviews.llvm.org/D18341
llvm-svn: 264003
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D18288
llvm-svn: 263852
|
|
|
|
|
|
| |
This reverts commit r263825, re-instating r263797.
llvm-svn: 263847
|
|
|
|
|
|
|
| |
constructor. This should fix the recent crashes on certain
architectures.
llvm-svn: 263845
|