Add 2 features: posix and windows.
Sometimes we want some specific tests only for posix and we use:
REQUIRES: posix
Sometimes we want some specific tests only for windows and we use:
REQUIRES: windows
Differential Revision: https://reviews.llvm.org/D29418
llvm-svn: 293827
Commands should expand the wildcards on Windows, the cmd prompt doesn't.
Because of that sancov was not finding the needed file.
To deal with this, we use ls and xargs from gnu win utils.
Differential Revision: https://reviews.llvm.org/D29374
llvm-svn: 293825
When disassembling a DSO, for calls to functions from the PLT, llvm-objdump only
prints the offset from the PLT, like: <.plt+0x30>.
While objdump and dumpbin print the function name, like:
<__sanitizer_cov_trace_pc_guard@plt>
When analyzing the coverage in libFuzzer we dissasemble and look for the calls
to __sanitizer_cov_trace_pc_guard.
So, this fails when using llvm-objdump on a DSO.
Differential Revision: https://reviews.llvm.org/D29372
llvm-svn: 293791
We need to set BINARY_DIR to: ${CMAKE_BINARY_DIR}/lib/Fuzzer/test , so the dll
is placed in the same directory than the test LLVMFuzzer-DSOTest, and is found
when executing that test.
As we are using CMAKE_CXX_CREATE_SHARED_LIBRARY to link the dll, we can't modify
the output directory for the import library. It will be created in the same
directory than the dll (in BINARY_DIR), no matter which value we set to
LIBRARY_DIR. So, if we set LIBRARY_DIR to a different directory than BINARY_DIR,
when linking LLVMFuzzer-DSOTest, cmake will look for the import library
LLVMFuzzer-DSO1.lib in LIBRARY_DIR, and won't find it, since it was created in
BINARY_DIR. So, for Windows, we need that LIBRARY_DIR and BINARY_DIR are the
same directory.
Differential Revision: https://reviews.llvm.org/D27870
llvm-svn: 292748
Don't check for InFuzzingThread() on Windows, since the AlarmHandler() is
always executed by a different thread from a thread pool.
If we don't add these changes, the alarm handler will never execute.
Note that we decided to ignore possible problem in the synchronization.
Differential Revision: https://reviews.llvm.org/D28723
llvm-svn: 292746
I add 2 changes to make the tests work on 32 bits and on 64 bits.
I change the size allocated to 0x20000000 and add the flag: -rss_limit_mb=300.
Otherwise the output for 32 bits and 64 bits is different.
For 64 bits the value 0xff000000 doesn't exceed kMaxAllowedMallocSize.
For 32 bits, kMaxAllowedMallocSize is set to 0xc0000000, so the call to
Allocate() will fail earlier printing "WARNING: AddressSanitizer failed to
allocate ..." , and wont't call malloc hooks.
So, we need to consider a size smaller than 2GB (so malloc doesn't fail on
32bits) and greater that the value provided by -rss_limit_mb.
Because of that I use: 0x20000000.
Differential Revision: https://reviews.llvm.org/D28706
llvm-svn: 292744
Fix libFuzzer when setting -close_fd_mask to a non-zero value.
In previous implementation, libFuzzer closes the file descriptors for
stdout/stderr. This has some disavantages:
For `fuzzer-fdmask.test`, we write directly to stdout and stderr using the
file streams stdout and stderr, after the file descriptors are closed, which is
undefined behavior. In Windows, in particular, this was making the test fail.
Also, if we close stdout and we open a new file in libFuzzer, we get the file
descriptor 1, which could generate problem if some code assumes file descriptors
refers to stdout and works directly writing to the file descriptor 1, but it
will be writing to the opened file (for example using std::cout).
Instead of closing the file descriptors, I redirect the output to /dev/null on
linux and nul on Windows.
Differential Revision: https://reviews.llvm.org/D28718
llvm-svn: 292743
This changes is necessary on Windows, where libraries doesn't include the prefix
"lib".
Differential Revision: https://reviews.llvm.org/D28710
llvm-svn: 292742
Update `ListFilesInDirRecursive` implementation on Windows to have the same
behavior than for Posix, when the directory doesn't exists and when it is empty.
Differential Revision: https://reviews.llvm.org/D28711
llvm-svn: 292741
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
We need to build all the tests with -O0, otherwise optimizations may merge some
basic blocks and the tests will fail.
In this diff, I simplify the cmake implementation and I remove the flags for
Windows too (/O[123s]).
Differential Revision: https://reviews.llvm.org/D28632
llvm-svn: 292737
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
Remove dependency on FileCheck, sancov and not for tests on Windows.
If LLVM_USE_SANITIZER=Address and LLVM_USE_SANITIZE_COVERAGE=YES, this will
trigger the building of dependencies with sanitizer instrumentation.
This will fail in Windows, since cmake will use link.exe for linking and won't
include compiler-rt libraries.
Differential Revision: https://reviews.llvm.org/D27993
llvm-svn: 292735
In order to use sanitizers on Windows, we need to link against many runtime
libraries which will depend on the target being created (executable or dll) and
the c runtime library used (MT/MD).
By default, cmake uses link.exe for linking, which fails because we don't
specify the appropiate dependencies. As we don't want to consider all of that
possible situations which depends on the implementation of the compiler-rt, the
simplest option is to change the rules for linking executables and shared
libraries, using the compiler instead of link.exe.
Clang driver will consider the sanitizer flags, and automatically provide the
required libraries to the linker.
Differential Revision: https://reviews.llvm.org/D27869
llvm-svn: 292669
Marcos Pividori