| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Code is already in compiler-rt
Reviewers: kcc
Subscribers: krytarowski, llvm-commits, hiraditya
Differential Revision: https://reviews.llvm.org/D38912
llvm-svn: 315937
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Augment SanitizerCoverage to insert maximum stack depth tracing for
use by libFuzzer. The new instrumentation is enabled by the flag
-fsanitize-coverage=stack-depth and is compatible with the existing
trace-pc-guard coverage. The user must also declare the following
global variable in their code:
thread_local uintptr_t __sancov_lowest_stack
https://bugs.llvm.org/show_bug.cgi?id=33857
Reviewers: vitalybuka, kcc
Reviewed By: vitalybuka
Subscribers: kubamracek, hiraditya, cfe-commits, llvm-commits
Differential Revision: https://reviews.llvm.org/D36839
llvm-svn: 311186
|
|
|
|
|
|
| |
(fprofile-instr-generate), Linux-only
llvm-svn: 310771
|
|
|
|
|
|
|
|
|
|
| |
Added the _sanitizer_cov_trace_const_cmp[1248] callbacks.
For now they are implemented the same way as _sanitizer_cov_trace_cmp[1248].
For more details, please see https://reviews.llvm.org/D36465.
Patch by Victor Chibotaru.
llvm-svn: 310592
|
|
|
|
| |
llvm-svn: 310326
|
|
|
|
| |
llvm-svn: 310325
|
|
|
|
| |
llvm-svn: 310324
|
|
|
|
|
|
| |
captured at run-time
llvm-svn: 310148
|
|
|
|
| |
llvm-svn: 309646
|
|
|
|
|
|
| |
flags for one test (for now)
llvm-svn: 309615
|
|
|
|
|
|
| |
and faster)
llvm-svn: 309443
|
|
|
|
|
|
| |
(commented out; real implementation needs to use inlined instrumentation)
llvm-svn: 308577
|
|
|
|
| |
llvm-svn: 307977
|
|
|
|
| |
llvm-svn: 307973
|
|
|
|
|
|
| |
libFuzzer. This is not fully functional yet, but simple tests work
llvm-svn: 305331
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I did this a long time ago with a janky python script, but now
clang-format has built-in support for this. I fed clang-format every
line with a #include and let it re-sort things according to the precise
LLVM rules for include ordering baked into clang-format these days.
I've reverted a number of files where the results of sorting includes
isn't healthy. Either places where we have legacy code relying on
particular include ordering (where possible, I'll fix these separately)
or where we have particular formatting around #include lines that
I didn't want to disturb in this patch.
This patch is *entirely* mechanical. If you get merge conflicts or
anything, just ignore the changes in this patch and run clang-format
over your #include lines in the files.
Sorry for any noise here, but it is important to keep these things
stable. I was seeing an increasing number of patches with irrelevant
re-ordering of #include lines because clang-format was used. This patch
at least isolates that churn, makes it easy to skip when resolving
conflicts, and gets us to a clean baseline (again).
llvm-svn: 304787
|
|
|
|
|
|
| |
instrumentation. It is less efficient and precise than -fsanitize-coverage=trace-pc-guard, but still works
llvm-svn: 299046
|
|
|
|
| |
llvm-svn: 298654
|
|
|
|
| |
llvm-svn: 298032
|
|
|
|
|
|
| |
Differential revision: https://reviews.llvm.org/D29831
llvm-svn: 294769
|
|
|
|
|
|
|
|
|
|
| |
We should always use unsigned long long to ensure 64 bits. On Windows, unsigned
long is 4 bytes. This was the reason why value-profile-cmp4.test was failing on
Windows.
Differential Revision: https://reviews.llvm.org/D29617
llvm-svn: 294390
|
|
|
|
| |
llvm-svn: 294061
|
|
|
|
|
|
|
|
| |
Reviewers: kcc
Differential Revision: https://reviews.llvm.org/D29502
llvm-svn: 294035
|
|
|
|
|
|
| |
inlined coverage instrumentation. NFC
llvm-svn: 293928
|
|
|
|
|
|
| |
MOD prime) on the hot path where it is useless anyway
llvm-svn: 293239
|
|
|
|
| |
llvm-svn: 293237
|
|
|
|
| |
llvm-svn: 293236
|
|
|
|
| |
llvm-svn: 293128
|
|
|
|
|
|
| |
sure it is not asan/msan-instrumented
llvm-svn: 293125
|
|
|
|
|
|
| |
dumping the PCs
llvm-svn: 293117
|
|
|
|
| |
llvm-svn: 292835
|
|
|
|
|
|
|
|
|
|
| |
Instead of directly using objdump, which is not present on Windows, we consider
different tools depending on the platform.
For Windows, we consider dumpbin and llvm-objdump.
Differential Revision: https://reviews.llvm.org/D28635
llvm-svn: 292739
|
|
|
|
|
|
|
|
| |
For Posix systems and Windows, we need to consider different cases.
Differential Revision: https://reviews.llvm.org/D28633
llvm-svn: 292738
|
|
|
|
|
|
|
|
|
| |
We need to expose Sanitizer Coverage's functions that are rewritten with a
different implementation, so compiler-rt's libraries have access to it.
Differential Revision: https://reviews.llvm.org/D28618
llvm-svn: 292736
|
|
|
|
| |
llvm-svn: 292695
|
|
|
|
| |
llvm-svn: 292681
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: The causes google/ossfuzz#84
Reviewers: kcc
Subscribers: mgorny
Differential Revision: https://reviews.llvm.org/D28827
llvm-svn: 292289
|
|
|
|
|
|
| |
code between cmp and memcmp handling)
llvm-svn: 292287
|
|
|
|
| |
llvm-svn: 290899
|
|
|
|
| |
llvm-svn: 290739
|
|
|
|
| |
llvm-svn: 290703
|
|
|
|
|
|
|
|
| |
Reviewers: kcc, vitalybuka
Differential Revision: https://reviews.llvm.org/D27942
llvm-svn: 290138
|
|
|
|
| |
llvm-svn: 290034
|
|
|
|
|
|
| |
(to make things faster). Also ensure that the signals from value profile do not intersect with the regular coverage
llvm-svn: 290031
|
|
|
|
| |
llvm-svn: 289999
|
|
|
|
|
|
| |
might be uninitialized
llvm-svn: 289680
|
|
|
|
|
|
| |
name while printing the coverage
llvm-svn: 289310
|
|
|
|
|
|
| |
ways. Also initialize a couple of Fuzzer:: members that might have been used uninitialized :(
llvm-svn: 288731
|
|
|
|
|
|
| |
covered dirs. Note: the Windows stub for DirName is left unimplemented
llvm-svn: 288276
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In an effort to get libfuzzer working on Windows, we need to make
a distinction between what functions require platform specific
code (e.g. different code on Windows vs Linux) and what code
doesn't. IO functions, for example, tend to be platform
specific.
This patch separates out some of the functions which will need
to have platform specific implementations into different headers,
so that we can then provide different implementations for each
platform.
Aside from that, this patch contains no functional change. It
is purely a re-organization.
Patch by Marcos Pividori
Differential Revision: https://reviews.llvm.org/D27230
llvm-svn: 288264
|