| 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
|
|
|
|
|
|
|
|
|
| |
This is because lib/Fuzzer doesn't really depend on llvm infrastucture.
It's not easy to access the llvm hardware_concurrency here.
Differential Reivision: https://reviews.llvm.org/D38481
llvm-svn: 314870
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The issue with std::thread::hardware_concurrency is that it forwards
to libc and some implementations (like glibc) don't take thread
affinity into consideration.
With this change a llvm program that can execute in only 2 cores will
use 2 threads, even if the machine has 32 cores.
This makes benchmarking a lot easier, but should also help if someone
doesn't want to use all cores for compilation for example.
llvm-svn: 314809
|
|
|
|
| |
llvm-svn: 310325
|
|
|
|
| |
llvm-svn: 307977
|
|
|
|
|
|
|
|
|
|
|
| |
std::thread::hardware_concurrency() returns an unsigned, so I modify
NumberOfCpuCores() to return unsigned too.
The number of cpus is used to define the number of workers, so I decided
to update the worker and jobs flags to be declared as unsigned too.
Differential Revision: https://reviews.llvm.org/D27685
llvm-svn: 289559
|
|
|
|
|
|
|
|
| |
This resubmits r288529, which was resubmitted because it broke a
fuzzer bot. According to kcc@ the test that broke was flakey
and it is unlikely to be a result of this patch.
llvm-svn: 288549
|
|
|
|
|
|
|
| |
This reverts commit r288529, as it seems to introduce some
problems on the Linux bots.
llvm-svn: 288533
|
|
|
|
|
|
|
|
|
|
| |
Pave the way for separating out platform specific
utility functions into separate files.
Patch by Marcos Pividori
Differential Revision: https://reviews.llvm.org/D27234
llvm-svn: 288529
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
and files.
Example of output:
COVERAGE:
COVERED: in DSO2(int) /pathto/DSO2.cpp:6
COVERED: in DSO2(int) /pathto/DSO2.cpp:8
COVERED: in DSO1(int) /pathto/DSO1.cpp:6
COVERED: in DSO1(int) /pathto/DSO1.cpp:8
COVERED: in LLVMFuzzerTestOneInput /pathto/DSOTestMain.cpp:16
COVERED: in LLVMFuzzerTestOneInput /pathto/DSOTestMain.cpp:19
COVERED: in LLVMFuzzerTestOneInput /pathto/DSOTestMain.cpp:25
COVERED: in LLVMFuzzerTestOneInput /pathto/DSOTestMain.cpp:26
MODULE_WITH_COVERAGE: /pathto/libLLVMFuzzer-DSO1.so
UNCOVERED_LINE: in DSO1(int) /pathto/DSO1.cpp:9
UNCOVERED_FUNC: in Uncovered1()
MODULE_WITH_COVERAGE: /pathto/libLLVMFuzzer-DSO2.so
UNCOVERED_LINE: in DSO2(int) /pathto/DSO2.cpp:9
UNCOVERED_FUNC: in Uncovered2()
MODULE_WITH_COVERAGE: /pathto/LLVMFuzzer-DSOTest
UNCOVERED_LINE: in LLVMFuzzerTestOneInput /pathto/DSOTestMain.cpp:21
UNCOVERED_LINE: in LLVMFuzzerTestOneInput /pathto/DSOTestMain.cpp:27
UNCOVERED_FILE: /pathto/DSOTestExtra.cpp
Several things are not perfect here:
* we are using objdump+awk instead of sancov because sancov does not support DSOs yet.
* this breaks in the presence of ASAN_OPTIONS=strip_path_prefix=...
(need to implement another API to get the module name by PC)
llvm-svn: 284554
|
|
|
|
|
|
| |
for RE2 that uses this flag
llvm-svn: 282458
|
|
|
|
| |
llvm-svn: 282121
|
|
|
|
| |
llvm-svn: 282044
|
|
|
|
|
|
| |
coverage from instrumented libc++
llvm-svn: 281933
|
|
|
|
|
|
| |
libFuzzer
llvm-svn: 281866
|
|
|
|
|
|
| |
and the mutation sequence
llvm-svn: 278975
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
on macOS.
The original `ExecuteCommand()` called `system()` from the C library.
The C library implementation of this on macOS contains a mutex which
serializes calls to `system()`. This prevented the `-jobs=` flag
from running copies of the fuzzing binary in parallel which is
the opposite of what is intended.
To fix this on macOS an alternative implementation of `ExecuteCommand()`
is provided that can be used concurrently. This is provided in
`FuzzerUtilDarwin.cpp` which is guarded to only compile code on Apple
platforms. The existing implementation has been moved to a new file
`FuzzerUtilLinux.cpp` which is guarded to only compile code on Linux.
This commit includes a simple test to check that LibFuzzer is being
executed in parallel when requested.
Differential Revision: https://reviews.llvm.org/D22742
llvm-svn: 278544
|
|
|
|
|
|
| |
the main fuzzing thread, print the message in the getrusage thread and exit.
llvm-svn: 270945
|
|
|
|
|
|
| |
function declarations. Add a test for -only_ascii. NFC intended
llvm-svn: 270900
|
|
|
|
|
|
|
|
| |
On Linux ``rusage.ru_maxrss`` is in KiB but on Mac OSX it is in bytes.
Differential Revision: http://reviews.llvm.org/D20410
llvm-svn: 270173
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The ``nprocs`` command does not exist under Mac OSX so use
``sysctl`` instead on that platform.
Whilst I'm here
* Use ``pclose()`` instead of ``fclose()`` which the ``popen()``
documentation says should be used.
* Check for errors that were previously unhandled.
Differential Revision: http://reviews.llvm.org/D20409
llvm-svn: 270172
|
|
|
|
|
|
| |
the OOM reproducer.
llvm-svn: 268821
|
|
|
|
| |
llvm-svn: 264338
|
|
|
|
|
|
|
|
| |
- unused sigaction/setitimer result (used in assert)
- unchecked fscanf return value
- signed/unsigned comparison
llvm-svn: 262472
|
|
|
|
|
|
| |
least something if ASan is not handlig the signals for us. Remove abort_on_timeout flag.
llvm-svn: 262415
|
|
|
|
| |
llvm-svn: 262084
|
|
|
|
| |
llvm-svn: 260829
|
|
|
|
|
|
| |
to avoid memory allocations on hot path
llvm-svn: 257985
|
|
|
|
|
|
| |
allocations
llvm-svn: 257713
|
|
|
|
|
|
| |
dictionary entries
llvm-svn: 257435
|
|
|
|
|
|
| |
Since libFuzzer should not depend on anything, just re-implement base64 encoder. PR25746
llvm-svn: 254784
|
|
|
|
|
|
| |
Aizatsky's idea)
llvm-svn: 252838
|
|
|
|
| |
llvm-svn: 252123
|
|
|
|
| |
llvm-svn: 250571
|
|
|
|
| |
llvm-svn: 246800
|
|
|
|
|
|
| |
remove ugly #ifdef
llvm-svn: 246689
|
|
|
|
| |
llvm-svn: 244559
|
|
|
|
| |
llvm-svn: 238081
|
|
|
|
|
|
| |
CORPUS' to synchronize with other processes
llvm-svn: 237617
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This adds a SHA1 implementation taken from public domain code.
The change is trivial, but as it involves third-party code I'd like
a second pair of eyes before commit.
LibFuzzer can not use SHA1 from openssl because openssl may not be available
and because we may be fuzzing openssl itself.
Using sha1sum via a pipe is too slow.
Test Plan: n/a
Reviewers: chandlerc
Reviewed By: chandlerc
Subscribers: majnemer, llvm-commits
Differential Revision: http://reviews.llvm.org/D9733
llvm-svn: 237400
|
|
|
|
| |
llvm-svn: 237198
|
|
|
|
|
|
| |
-workers=M is not. Update the docs.
llvm-svn: 237163
|
|
|
|
| |
llvm-svn: 233842
|
|
|
|
|
|
| |
flags.
llvm-svn: 233745
|
|
|
|
|
|
| |
fuzzer library based on LLVM_USE_SANITIZE_COVERAGE being set or unset.
llvm-svn: 227464
|
|
|
|
|
|
| |
for MSVC users. This reverts: 227445, 227395, 227389, 227357, 227254, 227252
llvm-svn: 227452
|
|
Summary:
A simple genetic in-process coverage-guided fuzz testing library.
I've used this fuzzer to test clang-format
(it found 12+ bugs, thanks djasper@ for the fixes!)
and it may also help us test other parts of LLVM.
So why not keep it in the LLVM repository?
I plan to add the cmake build rules later (in a separate patch, if that's ok)
and also add a clang-format-fuzzer target.
See README.txt for details.
Test Plan: Tests will follow separately.
Reviewers: djasper, chandlerc, rnk
Reviewed By: rnk
Subscribers: majnemer, ygribov, dblaikie, llvm-commits
Differential Revision: http://reviews.llvm.org/D7184
llvm-svn: 227252
|