summaryrefslogtreecommitdiffstats
path: root/compiler-rt/test
Commit message (Collapse)AuthorAgeFilesLines
...
* Restrict asan + dlopen testcase to x86Serge Guelton2019-07-181-2/+2
| | | | llvm-svn: 366436
* Relax regexp to detect failed interception by asanSerge Guelton2019-07-181-1/+1
| | | | | | This should fix failed detection on aarch64/ppc64/thumbv8... llvm-svn: 366432
* Fix asan infinite loop on undefined symbolSerge Guelton2019-07-181-0/+42
| | | | | | | | Fix llvm#39641 Differential Revision: https://reviews.llvm.org/D63877 llvm-svn: 366413
* hwasan: Use C++ driver for cfi.cc test.Peter Collingbourne2019-07-171-1/+1
| | | | | | | | | | | | | | It turns out that this test was only passing by accident. It was relying on the optimizer to remove the only reference to A's vtable by realizing that the CFI check will always fail. The vtable contains a reference to RTTI in libc++, which will be unresolved because the C driver won't link against it. This was found by my prototype implementation of HWASAN for globals, which happens to end up preserving the reference. Differential Revision: https://reviews.llvm.org/D64890 llvm-svn: 366389
* [ASan] Support `{f}puts(NULL)` on DarwinJulian Lettner2019-07-171-0/+16
| | | | | | | | | | | | | On Darwin, the man page states that "both fputs() and puts() print `(null)' if str is NULL." rdar://48227136 Reviewed By: Lekensteyn Differential Revision: https://reviews.llvm.org/D64773 llvm-svn: 366342
* Finish "Adapt -fsanitize=function to SANITIZER_NON_UNIQUE_TYPEINFO"Stephan Bergmann2019-07-161-3/+64
| | | | | | | | | | | | | | | | | | | | | i.e., recent 5745eccef54ddd3caca278d1d292a88b2281528b: * Bump the function_type_mismatch handler version, as its signature has changed. * The function_type_mismatch handler can return successfully now, so SanitizerKind::Function must be AlwaysRecoverable (like for SanitizerKind::Vptr). * But the minimal runtime would still unconditionally treat a call to the function_type_mismatch handler as failure, so disallow -fsanitize=function in combination with -fsanitize-minimal-runtime (like it was already done for -fsanitize=vptr). * Add tests. Differential Revision: https://reviews.llvm.org/D61479 llvm-svn: 366186
* [libFuzzer] Disable fork.test on AArch64Diana Picus2019-07-151-1/+1
| | | | | | This crashes sporadically on our AArch64 buildbots. Disable for now. llvm-svn: 366055
* Enable compiler-rt on SPARCRainer Orth2019-07-122-5/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch enables compiler-rt on SPARC targets. Most of the changes are straightforward: - Add 32 and 64-bit sparc to compiler-rt - lib/builtins/fp_lib.h needed to check if the int128_t and uint128_t types exist (which they don't on sparc) There's one issue of note: many asan tests fail to compile on Solaris/SPARC: fatal error: error in backend: Function "_ZN7testing8internal16BoolFromGTestEnvEPKcb": over-aligned dynamic alloca not supported. Therefore, while asan is still built, both asan and ubsan-with-asan testing is disabled. The goal is to check if asan keeps compiling on Solaris/SPARC. This serves asan in gcc, which doesn't have the problem above and works just fine. With this patch, sparcv9-sun-solaris2.11 test results are pretty good: Failing Tests (9): Builtins-sparc-sunos :: divtc3_test.c Builtins-sparcv9-sunos :: compiler_rt_logbl_test.c Builtins-sparcv9-sunos :: divtc3_test.c [...] UBSan-Standalone-sparc :: TestCases/TypeCheck/misaligned.cpp UBSan-Standalone-sparcv9 :: TestCases/TypeCheck/misaligned.cpp The builtin failures are due to Bugs 42493 and 42496. The tree contained a few additonal patches either currently in review or about to be submitted. Tested on sparcv9-sun-solaris2.11. Differential Revision: https://reviews.llvm.org/D40943 llvm-svn: 365880
* NFC: Unforget a colon in a few CHECK: directives.Artem Dergachev2019-07-121-2/+2
| | | | | | Differential Revision: https://reviews.llvm.org/D64526 llvm-svn: 365863
* Use clang driver for libfuzzer tests on WindowsReid Kleckner2019-07-112-5/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: There's no real reason to use clang-cl on Windows, the clang driver works just as well. This fixes a test which uses the -O0 flag, which was recently removed from clang-cl to match MSVC, which lacks this flag. While I'm here, remove the explicit -std=c++11 flag. Previously, this flag was necessary when the default C++ standard was C++98. Now that the default is C++14, this is no longer necessary. It's problematic on Windows, because the Visual C++ standard library relies on C++14 features, and attempting to compile it with C++11 results in errors. Rather than adding logic to conditionally set the standard to C++11 only on non-Win, this flag can be removed. See http://lab.llvm.org:8011/builders/clang-x64-windows-msvc and https://reviews.llvm.org/D64506. Reviewers: morehouse, thakis Subscribers: #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D64587 llvm-svn: 365841
* [profile][test] Fix Profile-* :: instrprof-merge.c etc. on SPARCRainer Orth2019-07-113-2/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | While working on https://reviews.llvm.org/D40900 (which effectively is about enabling compiler-rt on sparc these days), I came across two failing profile testcases: Profile-sparc :: instrprof-merge-match.test Profile-sparc :: instrprof-merge.c Profile-sparcv9 :: instrprof-merge-match.test Profile-sparcv9 :: instrprof-merge.c All of them crashed with a SIGBUS in __llvm_profile_merge_from_buffer: Thread 2 received signal SIGSEGV, Segmentation fault. [Switching to Thread 1 (LWP 1)] 0x00012368 in __llvm_profile_merge_from_buffer ( ProfileData=0x2384c <main.Buffer> "\377lprofR\201", ProfileSize=360) at /vol/llvm/src/llvm/local/projects/compiler-rt/lib/profile/InstrProfilingMerge.c:95 95 SrcDataEnd = SrcDataStart + Header->DataSize; where Header is insufficiently aligned for a strict-alignment target like SPARC. Fixed by forcing the alignment to uint64_t, the members of struct __llvm_profile_header, in the callers. Tested on sparcv9-sun-solaris2.11. https://reviews.llvm.org/D64498 llvm-svn: 365805
* Add NetBSD LSan supportKamil Rytarowski2019-07-111-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Combine few relatively small changes into one: - implement internal_ptrace() and internal_clone() for NetBSD - add support for stoptheworld based on the ptrace(2) API - define COMPILER_RT_HAS_LSAN for NetBSD - enable tests for NetBSD/amd64 Inspired by the original implementation by Christos Zoulas in netbsd/src for GCC. The implementation is in theory CPU independent through well defined macros across all NetBSD ports, however only the x86_64 version was tested. Reviewers: mgorny, dvyukov, vitalybuka, joerg, jfb Reviewed By: vitalybuka Subscribers: dexonsmith, jfb, srhines, kubamracek, llvm-commits, christos Tags: #llvm Differential Revision: https://reviews.llvm.org/D64057 llvm-svn: 365735
* Change another test I missed in r365724Nico Weber2019-07-111-1/+1
| | | | llvm-svn: 365725
* clang-cl: Remove -O0 optionNico Weber2019-07-1189-121/+121
| | | | | | | | | | | | cl.exe doesn't understand it; there's /Od instead. See also the review thread for r229575. Update lots of compiler-rt tests to use -Od instead of -O0. Ran `rg -l 'clang_cl.*O0' compiler-rt/test/ | xargs sed -i -c 's/-O0/-Od/'` Differential Revision: https://reviews.llvm.org/D64506 llvm-svn: 365724
* [ubsan][test] Restore float-divide-by-zero testFangrui Song2019-07-101-0/+1
| | | | | | Removed by rCTE365307 to fix buildbots. It can be restored now because D64317/rC365587 brought back -fsanitize=float-divide-by-zero llvm-svn: 365591
* hwasan: Improve precision of checks using short granule tags.Peter Collingbourne2019-07-094-64/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A short granule is a granule of size between 1 and `TG-1` bytes. The size of a short granule is stored at the location in shadow memory where the granule's tag is normally stored, while the granule's actual tag is stored in the last byte of the granule. This means that in order to verify that a pointer tag matches a memory tag, HWASAN must check for two possibilities: * the pointer tag is equal to the memory tag in shadow memory, or * the shadow memory tag is actually a short granule size, the value being loaded is in bounds of the granule and the pointer tag is equal to the last byte of the granule. Pointer tags between 1 to `TG-1` are possible and are as likely as any other tag. This means that these tags in memory have two interpretations: the full tag interpretation (where the pointer tag is between 1 and `TG-1` and the last byte of the granule is ordinary data) and the short tag interpretation (where the pointer tag is stored in the granule). When HWASAN detects an error near a memory tag between 1 and `TG-1`, it will show both the memory tag and the last byte of the granule. Currently, it is up to the user to disambiguate the two possibilities. Because this functionality obsoletes the right aligned heap feature of the HWASAN memory allocator (and because we can no longer easily test it), the feature is removed. Also update the documentation to cover both short granule tags and outlined checks. Differential Revision: https://reviews.llvm.org/D63908 llvm-svn: 365551
* [sanitizers][windows] FIX: Rtl-Heap Interception and testsMatthew G McGovern2019-07-0914-14/+14
| | | | | | | | | | | | - Adds interceptors for Rtl[Allocate|Free|Size|ReAllocate]Heap - Adds unit tests for the new interceptors and expands HeapAlloc tests to demonstrate new functionality. Reviewed as D62927 - adds fixes for ~win and x64 tests > llvm-svn: 365381 llvm-svn: 365424
* [sanitizers][windows] Rtl-Heap Interception and testsMatthew G McGovern2019-07-0922-4/+746
| | | | | | | | | - Adds interceptors for Rtl[Allocate|Free|Size|ReAllocate]Heap - Adds unit tests for the new interceptors and expands HeapAlloc tests to demonstrate new functionality. Reviewed as D62927 llvm-svn: 365422
* Revert "[sanitizers][windows] Rtl-Heap Interception and tests"JF Bastien2019-07-0822-746/+4
| | | | | | | | | | | | | | | | | | | | | | | | Causes build failure on clang-ppc64be-linux-lnt: compiler-rt/lib/asan/asan_malloc_win.cc:23:2: error: #error "Missing arch or unsupported platform for Windows." #error "Missing arch or unsupported platform for Windows." ^~~~~ compiler-rt/lib/asan/asan_malloc_win.cc:25:10: fatal error: heapapi.h: No such file or directory #include <heapapi.h> ^~~~~~~~~~~ compilation terminated. [39/1151] Building CXX object projects/compiler-rt/lib/asan/CMakeFiles/RTAsan.powerpc64.dir/asan_debugging.cc.o [40/1151] Building CXX object projects/compiler-rt/lib/asan/CMakeFiles/RTAsan.powerpc64.dir/asan_malloc_win.cc.o FAILED: projects/compiler-rt/lib/asan/CMakeFiles/RTAsan.powerpc64.dir/asan_malloc_win.cc.o /usr/bin/c++ -D_DEBUG -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Iprojects/compiler-rt/lib/asan -Icompiler-rt/lib/asan -Iinclude -I/home/buildbots/ppc64be-clang-lnt-test/clang-ppc64be-lnt/llvm/include -Icompiler-rt/lib/asan/.. -fPIC -fvisibility-inlines-hidden -Werror=date-time -std=c++11 -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wimplicit-fallthrough -Wno-maybe-uninitialized -Wno-noexcept-type -Wdelete-non-virtual-dtor -Wno-comment -fdiagnostics-color -ffunction-sections -fdata-sections -Wall -std=c++11 -Wno-unused-parameter -O2 -UNDEBUG -m64 -fPIC -fno-builtin -fno-exceptions -fomit-frame-pointer -funwind-tables -fno-stack-protector -fvisibility=hidden -fno-lto -O3 -g -Wno-variadic-macros -Wno-non-virtual-dtor -fno-rtti -MD -MT projects/compiler-rt/lib/asan/CMakeFiles/RTAsan.powerpc64.dir/asan_malloc_win.cc.o -MF projects/compiler-rt/lib/asan/CMakeFiles/RTAsan.powerpc64.dir/asan_malloc_win.cc.o.d -o projects/compiler-rt/lib/asan/CMakeFiles/RTAsan.powerpc64.dir/asan_malloc_win.cc.o -c compiler-rt/lib/asan/asan_malloc_win.cc compiler-rt/lib/asan/asan_malloc_win.cc:23:2: error: #error "Missing arch or unsupported platform for Windows." #error "Missing arch or unsupported platform for Windows." ^~~~~ compiler-rt/lib/asan/asan_malloc_win.cc:25:10: fatal error: heapapi.h: No such file or directory #include <heapapi.h> ^~~~~~~~~~~ llvm-svn: 365384
* [sanitizers][windows] Rtl-Heap Interception and testsMatthew G McGovern2019-07-0822-4/+746
| | | | | | | | | - Adds interceptors for Rtl[Allocate|Free|Size|ReAllocate]Heap - Adds unit tests for the new interceptors and expands HeapAlloc tests to demonstrate new functionality. Reviewed as D62927 llvm-svn: 365381
* Revert "[TSan] Attempt to fix iOS on-device test"Julian Lettner2019-07-081-4/+7
| | | | | | This reverts commit a2ca358291a3a621bfae66eeb01f51eeb69d2dd4. llvm-svn: 365375
* [ubsan][test] Fix cast-overflow.cpp and delete float-divide-by-zero test ↵Fangrui Song2019-07-082-2/+1
| | | | | | after D63793/rC365272 llvm-svn: 365307
* [ubsan][test] Fix several UBSan-* :: TestCases/ImplicitConversion tests on ↵Rainer Orth2019-07-086-120/+120
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Solaris A couple of UBSan-* :: TestCases/ImplicitConversion testcases FAIL on Solaris/x86 (and Solaris/SPARC with https://reviews.llvm.org/D40900): FAIL: UBSan-AddressSanitizer-i386 :: TestCases/ImplicitConversion/signed-integer-truncation-or-sign-change-blacklist.c (49187 of 49849) ******************** TEST 'UBSan-AddressSanitizer-i386 :: TestCases/ImplicitConversion/signed-integer-truncation-or-sign-change-blacklist.c' FAILED ******************** [...] Command Output (stderr): -- /vol/llvm/src/compiler-rt/local/test/ubsan/TestCases/ImplicitConversion/signed-integer-truncation-or-sign-change-blacklist.c:53:11: error: CHECK: expected string not found in input // CHECK: {{.*}}signed-integer-truncation-or-sign-change-blacklist.c:[[@LINE-1]]:10: runtime error: implicit conversion from type '{{.*}}' (aka 'unsigned int') of value 4294967295 (32-bit, unsigned) to type '{{.*}}' (aka 'signed char') changed the value to -1 (8-bit, signed) ^ <stdin>:1:1: note: scanning from here /vol/llvm/src/compiler-rt/local/test/ubsan/TestCases/ImplicitConversion/signed-integer-truncation-or-sign-change-blacklist.c:52:10: runtime error: implicit conversion from type 'uint32_t' (aka 'unsigned int') of value 4294967295 (32-bit, unsigned) to type 'int8_t' (aka 'char') changed the value to -1 (8-bit, signed) ^ <stdin>:1:1: note: with "@LINE-1" equal to "52" /vol/llvm/src/compiler-rt/local/test/ubsan/TestCases/ImplicitConversion/signed-integer-truncation-or-sign-change-blacklist.c:52:10: runtime error: implicit conversion from type 'uint32_t' (aka 'unsigned int') of value 4294967295 (32-bit, unsigned) to type 'int8_t' (aka 'char') changed the value to -1 (8-bit, signed) ^ <stdin>:1:69: note: possible intended match here /vol/llvm/src/compiler-rt/local/test/ubsan/TestCases/ImplicitConversion/signed-integer-truncation-or-sign-change-blacklist.c:52:10: runtime error: implicit conversion from type 'uint32_t' (aka 'unsigned int') of value 4294967295 (32-bit, unsigned) to type 'int8_t' (aka 'char') changed the value to -1 (8-bit, signed) ^ This is always a difference for int8_t where signed char is expected, but only char seen. I could trace this to <sys/int_types.h> which has /* * Basic / Extended integer types * * The following defines the basic fixed-size integer types. * * Implementations are free to typedef them to Standard C integer types or * extensions that they support. If an implementation does not support one * of the particular integer data types below, then it should not define the * typedefs and macros corresponding to that data type. Note that int8_t * is not defined in -Xs mode on ISAs for which the ABI specifies "char" * as an unsigned entity because there is no way to define an eight bit * signed integral. */ #if defined(_CHAR_IS_SIGNED) typedef char int8_t; #else #if defined(__STDC__) typedef signed char int8_t; #endif #endif _CHAR_IS_SIGNED is always defined on both sparc and x86. Since it seems ok to have either form, I've changed the affected tests to use '{{(signed )?}}char' instead of 'signed char'. Tested on x86_64-pc-solaris2.11, sparcv9-sun-solaris2.11, and x86_64-pc-linux-gnu. Differential Revision: https://reviews.llvm.org/D63984 llvm-svn: 365303
* [ubsan][test] Don't disable ubsan testing on 64-bit Solaris/x86Rainer Orth2019-07-082-8/+4
| | | | | | | | | | | Unlike asan, which isn't supported yet on 64-bit Solaris/x86, there's no reason to disable ubsan. This patch does that, but keeps the 64-bit ubsan-with-asan tests disabled. Tested on x86_64-pc-solaris2.11. Differential Revision: https://reviews.llvm.org/D63982 llvm-svn: 365302
* [TSan] Attempt to fix iOS on-device testJulian Lettner2019-07-061-4/+4
| | | | llvm-svn: 365257
* XFAIL a few failing TSan-fiber tests for iOSJulian Lettner2019-07-055-0/+5
| | | | llvm-svn: 365254
* Remove `XFAIL: ios` from test that passes in CIJulian Lettner2019-07-051-1/+0
| | | | llvm-svn: 365253
* [GWP-ASan] Add generic unwinders and structure backtrace output.Mitch Phillips2019-07-0212-21/+22
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: Adds two flavours of generic unwinder and all the supporting cruft. If the supporting allocator is okay with bringing in sanitizer_common, they can use the fast frame-pointer based unwinder from sanitizer_common. Otherwise, we also provide the backtrace() libc-based unwinder as well. Of course, the allocator can always specify its own unwinder and unwinder-symbolizer. The slightly changed output format is exemplified in the first comment on this patch. It now better incorporates backtrace information, and displays allocation details on the second line. Reviewers: eugenis, vlad.tsyrklevich Reviewed By: eugenis, vlad.tsyrklevich Subscribers: srhines, kubamracek, mgorny, cryptoad, #sanitizers, llvm-commits, morehouse Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D63841 llvm-svn: 364941
* hwasan: Teach the runtime to identify the local variable being accessed in ↵Peter Collingbourne2019-06-273-13/+53
| | | | | | | | | | | | | | UAR reports. Each function's PC is recorded in the ring buffer. From there we can access the function's local variables and reconstruct the tag of each one with the help of the information printed by llvm-symbolizer's new FRAME command. We can then find the variable that was likely being accessed by matching the pointer's tag against the reconstructed tag. Differential Revision: https://reviews.llvm.org/D63469 llvm-svn: 364607
* [compiler-rt] Rename lit.*.cfg.* -> lit.*.cfg.py.*Reid Kleckner2019-06-27102-113/+113
| | | | | | | | | | | | | These lit configuration files are really Python source code. Using the .py file extension helps editors and tools use the correct language mode. LLVM and Clang already use this convention for lit configuration, this change simply applies it to all of compiler-rt. Reviewers: vitalybuka, dberris Differential Revision: https://reviews.llvm.org/D63658 llvm-svn: 364591
* [compiler-rt][test] Set shared_libasan_path in test/asan/lit.cfg on SolarisRainer Orth2019-06-261-1/+1
| | | | | | | | | | | | While checking warnings from the Solaris buildbots, I noticed llvm-lit: /opt/llvm-buildbot/home/solaris11-amd64/clang-solaris11-amd64/llvm/projects/compiler-rt/test/asan/lit.cfg:119: warning: %shared_libasan substitution not set but dynamic ASan is available. Fixed as follows. Tested on x86_64-pc-solaris2.11. Differential Revision: https://reviews.llvm.org/D63761 llvm-svn: 364394
* Follow up fix for r364366.Dan Liew2019-06-261-1/+1
| | | | | | | | | When setting the parallelism group support MSan and use a syntactically compact condition. rdar://problem/51754620 llvm-svn: 364369
* Add USan+ASan and UBSan+TSan tests to shadow-memory lit parallelism group.Dan Liew2019-06-261-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Previously we were running these tests without the "shadow-memory" lit parallelism group even though we run the ASan and TSan tests in this group to avoid problems with many processes using shadow memory in parallel. On my local machine the UBSan+TSan tests would previously timeout if I set a 30 second per test limit. With this change I no longer see individual test timeouts. This change was made in response to the greendragon build bot reporting individual test timeouts for these tests. Given that the UBSan+ASan and UBSan+TSan tests did not have a parallelism group previously it's likely that some other change has caused the performance degradation. However I haven't been able to track down the cause so until we do, this change seems reasonable and is in line with what we already do with ASan and TSan tests. rdar://problem/51754620 Reviewers: yln, kubamracek, vsk, samsonov Subscribers: #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D63797 llvm-svn: 364366
* [sanitizer] Enabled getpw_getgr.cc on iOSVitaly Buka2019-06-251-1/+0
| | | | | | | | | | | | | | Reviewers: kubamracek, delcypher, yln Reviewed By: delcypher Subscribers: yln, delcypher, llvm-commits, kubamracek, #sanitizers Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D57786 llvm-svn: 364261
* (Reland with changes) Adding a function for setting coverage output file.Sajjad Mirza2019-06-242-0/+74
| | | | | | | | | | | | | | | | | | | | | | | Summary: User code can open a file on its own and pass it to the runtime, rather than specifying a name and having the runtime open the file. This supports the use case where a process cannot open a file on its own but can receive a file descriptor from another process. Relanding https://reviews.llvm.org/D62541. The original revision unlocked the file before calling flush, this revision fixes that. Reviewers: Dor1s, davidxl Reviewed By: Dor1s Subscribers: #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D63581 llvm-svn: 364231
* [asan] Quote the path to the Python exe in case it has spacesReid Kleckner2019-06-211-2/+10
| | | | | | | | | | | | | These days, Python 3 installs itself into Program Files, so it often has spaces. At first, I resisted this, and I reinstalled it globally into C:/Python37, similar to the location used for Python 2.7. But then I updated VS 2019, and it uninstalled my copy of Python and installed a new one inside "C:/Program Files (x86)/Microsoft Visual Studio/". At this point, I gave up and switched to using its built-in version of Python. However, now these tests fail, and have to be made aware of the possibility of spaces in paths. :( llvm-svn: 364077
* [libFuzzer] split DataFlow.cpp into two .cpp files, one of which can be ↵Kostya Serebryany2019-06-213-4/+7
| | | | | | compiled w/o dfsan to speed things up (~25% speedup) llvm-svn: 364002
* [libFuzzer] ensure that DFT and autofocus works for C++ (mangled) functionsKostya Serebryany2019-06-202-5/+10
| | | | llvm-svn: 363905
* Revert r363633 "[CMake] Fix the value of `config.target_cflags` for ↵Hans Wennborg2019-06-194-71/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | non-macOS Apple platforms. Attempt #2." This caused Chromium's clang package to stop building, see comment on https://reviews.llvm.org/D61242 for details. > Summary: > The main problem here is that `-*-version_min=` was not being passed to > the compiler when building test cases. This can cause problems when > testing on devices running older OSs because Clang would previously > assume the minimum deployment target is the the latest OS in the SDK > which could be much newer than what the device is running. > > Previously the generated value looked like this: > > `-arch arm64 -isysroot > <path_to_xcode>/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS12.1.sdk` > > With this change it now looks like: > > `-arch arm64 -stdlib=libc++ -miphoneos-version-min=8.0 -isysroot > <path_to_xcode>/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS12.1.sdk` > > This mirrors the setting of `config.target_cflags` on macOS. > > This change is made for ASan, LibFuzzer, TSan, and UBSan. > > To implement this a new `get_test_cflags_for_apple_platform()` function > has been added that when given an Apple platform name and architecture > returns a string containing the C compiler flags to use when building > tests. This also calls a new helper function `is_valid_apple_platform()` > that validates Apple platform names. > > This is the second attempt at landing the patch. The first attempt (r359305) > had to be reverted (r359327) due to a buildbot failure. The problem was > that calling `get_test_cflags_for_apple_platform()` can trigger a CMake > error if the provided architecture is not supported by the current > CMake configuration. Previously, this could be triggered by passing > `-DCOMPILER_RT_ENABLE_IOS=OFF` to CMake. The root cause is that we were > generating test configurations for a list of architectures without > checking if the relevant Sanitizer actually supported that architecture. > We now intersect the list of architectures for an Apple platform > with `<SANITIZER>_SUPPORTED_ARCH` (where `<SANITIZER>` is a Sanitizer > name) to iterate through the correct list of architectures. > > rdar://problem/50124489 > > Reviewers: kubamracek, yln, vsk, juliehockett, phosek > > Subscribers: mgorny, javed.absar, kristof.beyls, #sanitizers, llvm-commits > > Tags: #llvm, #sanitizers > > Differential Revision: https://reviews.llvm.org/D61242 llvm-svn: 363779
* Disable recently added Darwin symbolization tests for iOS.Dan Liew2019-06-182-0/+2
| | | | | | | | These tests won't necessarily work because the reported modules paths from the device don't match what's on the host and so offline symbolization fails. llvm-svn: 363641
* [NFC] Split `Darwin/asan-symbolize-partial-report-with-module-map.cc`.Dan Liew2019-06-182-20/+42
| | | | | | | Split `Darwin/asan-symbolize-partial-report-with-module-map.cc` into two separate test cases due to them testing slightly different things. llvm-svn: 363640
* [asan_symbolize] Teach `asan_symbolize.py` to symbolicate partially ↵Dan Liew2019-06-181-0/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | symbolicated ASan reports. Summary: The use case here is to be able symbolicate ASan reports that might be partially symbolicated, in particular where the function name is known but no source location is available. This can be caused by missing debug info. Previously we would only try to symbolicate completely unsymbolicated reports. The code currently contains an unfortunate quirk to handle a darwin specific bug (rdar://problem/49784442) in the way partially symbolicated reports are emitted when the source location is missing. rdar://problem/49476995 Reviewers: kubamracek, yln, samsonov, dvyukov, vitalybuka Subscribers: aprantl, #sanitizers, llvm-commits Tags: #llvm, #sanitizers Differential Revision: https://reviews.llvm.org/D60533 llvm-svn: 363639
* hwasan: Use bits [3..11) of the ring buffer entry address as the base stack tag.Peter Collingbourne2019-06-173-13/+16
| | | | | | | | | | | | | | This saves roughly 32 bytes of instructions per function with stack objects and causes us to preserve enough information that we can recover the original tags of all stack variables. Now that stack tags are deterministic, we no longer need to pass -hwasan-generate-tags-with-calls during check-hwasan. This also means that the new stack tag generation mechanism is exercised by check-hwasan. Differential Revision: https://reviews.llvm.org/D63360 llvm-svn: 363636
* [CMake] Fix the value of `config.target_cflags` for non-macOS Apple ↵Dan Liew2019-06-174-35/+71
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | platforms. Attempt #2. Summary: The main problem here is that `-*-version_min=` was not being passed to the compiler when building test cases. This can cause problems when testing on devices running older OSs because Clang would previously assume the minimum deployment target is the the latest OS in the SDK which could be much newer than what the device is running. Previously the generated value looked like this: `-arch arm64 -isysroot <path_to_xcode>/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS12.1.sdk` With this change it now looks like: `-arch arm64 -stdlib=libc++ -miphoneos-version-min=8.0 -isysroot <path_to_xcode>/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS12.1.sdk` This mirrors the setting of `config.target_cflags` on macOS. This change is made for ASan, LibFuzzer, TSan, and UBSan. To implement this a new `get_test_cflags_for_apple_platform()` function has been added that when given an Apple platform name and architecture returns a string containing the C compiler flags to use when building tests. This also calls a new helper function `is_valid_apple_platform()` that validates Apple platform names. This is the second attempt at landing the patch. The first attempt (r359305) had to be reverted (r359327) due to a buildbot failure. The problem was that calling `get_test_cflags_for_apple_platform()` can trigger a CMake error if the provided architecture is not supported by the current CMake configuration. Previously, this could be triggered by passing `-DCOMPILER_RT_ENABLE_IOS=OFF` to CMake. The root cause is that we were generating test configurations for a list of architectures without checking if the relevant Sanitizer actually supported that architecture. We now intersect the list of architectures for an Apple platform with `<SANITIZER>_SUPPORTED_ARCH` (where `<SANITIZER>` is a Sanitizer name) to iterate through the correct list of architectures. rdar://problem/50124489 Reviewers: kubamracek, yln, vsk, juliehockett, phosek Subscribers: mgorny, javed.absar, kristof.beyls, #sanitizers, llvm-commits Tags: #llvm, #sanitizers Differential Revision: https://reviews.llvm.org/D61242 llvm-svn: 363633
* [GWP-ASan] Integration with Scudo [5].Mitch Phillips2019-06-1719-5/+279
| | | | | | | | | | | | | | | | | | | | | | Summary: See D60593 for further information. This patch adds GWP-ASan support to the Scudo hardened allocator. It also implements end-to-end integration tests using Scudo as the backing allocator. The tests include crash handling for buffer over/underflow as well as use-after-free detection. Reviewers: vlad.tsyrklevich, cryptoad Reviewed By: vlad.tsyrklevich, cryptoad Subscribers: kubamracek, mgorny, #sanitizers, llvm-commits, morehouse Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D62929 llvm-svn: 363584
* [libFuzzer] implement a better queue for the fork mode. Add an internal flag ↵Kostya Serebryany2019-06-141-1/+1
| | | | | | -stop_file to allow graceful shutdown of fuzzing. Enhance the logging in the fork mode llvm-svn: 363470
* [libFuzzer] simplify the DFT trace collection using the new faster DFSan ↵Kostya Serebryany2019-06-143-48/+96
| | | | | | mode that traces up to 16 labels at a time and never runs out of labels. Second attempt. This time with a fix for windows (putenv instead of setenv)) llvm-svn: 363445
* [libFuzzer] Disable len_control by default if LLVMFuzzerCustomMutator is used.Max Moroz2019-06-141-0/+6
| | | | | | | | | | | | | | | | | | | | | | Summary: Some custom mutators may not peform well when size restriction is enforced by len_control. Because of that, it's safer to disable len_control by default in such cases, but still allow users to enable it manually. Bug example: https://bugs.chromium.org/p/chromium/issues/detail?id=919530. Tested manually with LPM-based and regular fuzz targets. Reviewers: kcc, vitalybuka, metzman Reviewed By: kcc, metzman Subscribers: delcypher, #sanitizers, llvm-commits Tags: #llvm, #sanitizers Differential Revision: https://reviews.llvm.org/D63334 llvm-svn: 363443
* Revert r363326 "[libFuzzer] simplify the DFT trace collection using the new ↵Hans Wennborg2019-06-143-96/+48
| | | | | | | | | | | | faster DFSan mode that traces up to 16 labels at a time and never runs out of labels." It broke the Windows build: C:\b\s\w\ir\cache\builder\src\third_party\llvm\compiler-rt\lib\fuzzer\FuzzerDataFlowTrace.cpp(243): error C3861: 'setenv': identifier not found This also reverts the follow-up r363327. llvm-svn: 363358
* fix whitespacesKostya Serebryany2019-06-131-3/+1
| | | | llvm-svn: 363327
OpenPOWER on IntegriCloud