The `check-fuzzer` runs fine with cl build llvm, but the following lit
tests fail with clang-cl build llvm
```
********************
Timed Out Tests (2):
libFuzzer-x86_64-default-Windows :: fork-ubsan.test
libFuzzer-x86_64-default-Windows :: fuzzer-oom.test
********************
Failed Tests (22):
libFuzzer-x86_64-default-Windows :: acquire-crash-state.test
libFuzzer-x86_64-default-Windows :: cross_over_copy.test
libFuzzer-x86_64-default-Windows :: cross_over_insert.test
libFuzzer-x86_64-default-Windows :: exit_on_src_pos.test
libFuzzer-x86_64-default-Windows :: fuzzer-alignment-assumption.test
libFuzzer-x86_64-default-Windows :: fuzzer-implicit-integer-sign-change.test
libFuzzer-x86_64-default-Windows :: fuzzer-implicit-signed-integer-truncation-or-sign-change.test
libFuzzer-x86_64-default-Windows :: fuzzer-implicit-signed-integer-truncation.test
libFuzzer-x86_64-default-Windows :: fuzzer-implicit-unsigned-integer-truncation.test
libFuzzer-x86_64-default-Windows :: fuzzer-printcovpcs.test
libFuzzer-x86_64-default-Windows :: fuzzer-timeout.test
libFuzzer-x86_64-default-Windows :: fuzzer-ubsan.test
libFuzzer-x86_64-default-Windows :: minimize_crash.test
libFuzzer-x86_64-default-Windows :: minimize_two_crashes.test
libFuzzer-x86_64-default-Windows :: null-deref-on-empty.test
libFuzzer-x86_64-default-Windows :: null-deref.test
libFuzzer-x86_64-default-Windows :: print-func.test
libFuzzer-x86_64-default-Windows :: stack-overflow-with-asan.test
libFuzzer-x86_64-default-Windows :: trace-malloc-2.test
libFuzzer-x86_64-default-Windows :: trace-malloc-unbalanced.test
libFuzzer-x86_64-default-Windows :: trace-malloc.test
```
The related commits are
53a81d4d26
and
e31efd8f6f.
Following the change in
e31efd8f6f
can fix these failures.
As for the issue mentioned in the comment that alternatename support in
clang not good enough(https://bugs.llvm.org/show_bug.cgi?id=40218). I
find that using `__builtin_function_start(func)` instead of directly
using `func` would make it work as intended.
In C, it is UB to call `memcmp(NULL, NULL, 0)`, `memcpy(NULL, NULL, 0)`,
etc. Unfortunately, `(NULL, 0)` is the natural representation of an
empty sequence of objects and extremely common in real world code. As a
result, all C code, and C++ code which calls into C functions, must
carefully guard all calls to `memcpy`.
This is a serious, real world usability issue in C and should be fixed
in the language (see #49459). In the meantime, pay the cost of the extra
branch to avoid tripping UBSan in libFuzzer. Once the usability problem
in C has been fixed, these checks can be removed.
Fixes#96772
This fixes a few of these warnings, when building with Clang ToT on
Windows:
```
[622/7618] Building CXX object
projects\compiler-rt\lib\sanitizer_common\CMakeFiles\RTSanitizerCommonSymbolizer.x86_64.dir\sanitizer_symbolizer_win.cpp.obj
C:\src\git\llvm-project\compiler-rt\lib\sanitizer_common\sanitizer_symbolizer_win.cpp(74,3):
warning: cast from 'FARPROC' (aka 'long long (*)()') to
'decltype(::StackWalk64) *' (aka 'int (*)(unsigned long, void *, void *,
_tagSTACKFRAME64 *, void *, int (*)(void *, unsigned long long, void *,
unsigned long, unsigned long *), void *(*)(void *, unsigned long long),
unsigned long long (*)(void *, unsigned long long), unsigned long long
(*)(void *, void *, _tagADDRESS64 *))') converts to incompatible
function type [-Wcast-function-type-mismatch]
```
This is similar to https://github.com/llvm/llvm-project/pull/97905
Update the folder titles for targets in the monorepository that have not
seen taken care of for some time. These are the folders that targets are
organized in Visual Studio and XCode
(`set_property(TARGET <target> PROPERTY FOLDER "<title>")`)
when using the respective CMake's IDE generator.
* Ensure that every target is in a folder
* Use a folder hierarchy with each LLVM subproject as a top-level folder
* Use consistent folder names between subprojects
* When using target-creating functions from AddLLVM.cmake, automatically
deduce the folder. This reduces the number of
`set_property`/`set_target_property`, but are still necessary when
`add_custom_target`, `add_executable`, `add_library`, etc. are used. A
LLVM_SUBPROJECT_TITLE definition is used for that in each subproject's
root CMakeLists.txt.
libfuzzer's -jobs option will, depending on the number of CPUs, spin up
a
WorkerThread and end up printing the log file using CopyFileToErr.
This leads to an MSan false positive. This patch disables the MSan
interceptor checks,
similarly to other instances in https://reviews.llvm.org/D48891
Side-note: this false positive issue first appeared when printf()
was replaced by puts() (90b4d1bcb2).
The interceptor check was always present; however, MSan does not
check_printf by default.
All these unit tests already include ${COMPILER_RT_GTEST_SOURCE} as an
input source file and the target llvm_gtest does not exist for
standalone builds. Currently the DEPS argument is ignored for standalone
builds so the missing target is not a problem, but as part of fixing a
build race for standalone builds I am planning to include those
dependencies in COMPILER_RT_TEST_STANDALONE_BUILD_LIBS configurations.
Reviewed By: vitalybuka
Pull Request: https://github.com/llvm/llvm-project/pull/83649
SetThreadDescription symbol needs to be dynamically loaded before usage.
Then using a wide string buffer, since we re using a null terminated
string, we can use MultiByteToWideChar -1 as 4th argument to finally set
the thread name.
Previously `SetThreadDescription` was called directly causing crash.
It was reverted in dd3aa26fc8
This updates the signal handle thread coordinating to use a user signal
bit on the SignalHandlerEvent to coordinate shutdown instead of closing
the event handle. Closing the event handle is racy as the handle may be
closed before the signal handler thread resolves the handle value in
_zx_object_wait_many() and we would like to make this an explicit error.
Using the user signal bit 1 instead and then closing the event object
after the signal handler thread is joined cannot race as the wait will
terminate whether the signal is raised before or after the wait begins.
The Android LLVM build system builds the arm64 fuzzer lib without
HWASan, but then applications that enable HWASan can generated an object
file with a HWASan-ified version of some libc++ symbols (e.g.
`std::__1::piecewise_construct`). The linker can choose the HWASan-ified
definition, but then it cannot resolve the relocation from
libclang_rt.fuzzer-aarch64-android.a to this symbol because the high
bits of the address are unexpectedly set. This produces an error:
```
relocation R_AARCH64_ADR_PREL_PG_HI21 out of range
```
Fix this problem by linking a custom isolated libc++ into Android's
fuzzer library.
We need to pass through ANDROID_NATIVE_API_LEVEL so that the libc++ for
32-bit Android (API < 24) uses LLVM_FORCE_SMALLFILE_FOR_ANDROID.
Instead of a linear scan, use a bitset to track rarity of features. This
improves fuzzer throughput rather dramatically (close to 2x) in early
exploratory phases; in steady state this seems to improve fuzzing
throughput by ~15% according to perf.
The benchmarks are done on an executable with ~100k features, so the
results may change based on the executable that's being fuzzed.
kFeatureSetSize is 2M so the bitset is adding 256 KB to
sizeof(InputCorpus), but this should be fine since there's already three
arrays indexed by feature index for a total of 200 MB.
Switch from C++11 to C++14 as fuzzer requires std::chrono and stdlibc++
doesn't provide chrono literals when using -std=c++11.
Also remove 'u' from ar command to fix this warning: ar: `u' modifier
ignored since `D' is the default (see `U')
Api available since Windows Server 2016/Windows 10 1607
Reviewers: vitalybuka
Reviewed-By: vitalybuka
Differential Revison: https://reviews.llvm.org/D156317
Api available since Windows Server 2016/Windows 10 1607.
Reviewers: vitalybuka
Reviewed-By: vitalybuka
Differential Revision: https://reviews.llvm.org/D156317
Allow to have a name for workers in case the fuzzed code is itself using threads.
Reviewers: vitalybuka
Reviewed-By: vitalybuka
Differential Revision: https://reviews.llvm.org/D155754
Don't hard code the page in FuzzerUtil.h, this breaks on
e.g. LoongArch which defaults to a 16KiB page size.
Reviewed By: #sanitizers, vitalybuka
Differential Revision: https://reviews.llvm.org/D140607
This reverts commit a2b677e815.
reverting
Differential Revision: https://reviews.llvm.org/D140607
because <sys/auxv.h> and getauxval() are not available on macOS;
this change is breaking the mac CI bots.
Don't hard code the page in FuzzerUtil.h, this breaks on
e.g. LoongArch which defaults to a 16KiB page size.
Reviewed By: #sanitizers, vitalybuka
Differential Revision: https://reviews.llvm.org/D140607
This is an ongoing series of commits that are reformatting our
Python code. This catches the last of the python files to
reformat. Since they where so few I bunched them together.
Reformatting is done with `black`.
If you end up having problems merging this commit because you
have made changes to a python file, the best way to handle that
is to run git checkout --ours <yourfile> and then reformat it
with black.
If you run into any problems, post to discourse about it and
we will try to help.
RFC Thread below:
https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style
Reviewed By: jhenderson, #libc, Mordante, sivachandra
Differential Revision: https://reviews.llvm.org/D150784
This fixes building the tests so that the tests can start
executing (even if there still are lots of failures).
Differential Revision: https://reviews.llvm.org/D147648
CopyFileToErr() uses Printf("%s", ...) which fails with a negative size on
files >2Gb (Its path is through var-args wrappers to an unnecessary "%s"
expansion and subject to int overflows) Using puts() in place of printf()
bypasses this path and writes the string directly to stderr. This avoids the
present loss of data when a crashed worker has generated >2Gb of output.
rdar://99384640
Reviewed By: yln, rsundahl
Differential Revision: https://reviews.llvm.org/D146189
