summaryrefslogtreecommitdiff
path: root/test
Commit message (Collapse)AuthorAgeFilesLines
* [builtins][test] Avoid unportable mmap call in clear_cache_test.cHEADmasterRainer Orth2019-10-221-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Within the last two weeks, the Builtins-*-sunos :: clear_cache_test.c started to FAIL on Solaris. Running it under truss shows mmap(0x00000000, 128, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANON, 0, 0) Err#22 EINVAL _exit(1) While there are several possible reasons mmap can return EINVAL on Solaris, it turns out it's this one (from mmap(2)): MAP_ANON was specified, but the file descriptor was not -1. And indeed even the Linux mmap(2) documents this as unportable: MAP_ANONYMOUS The mapping is not backed by any file; its contents are initial‐ ized to zero. The fd argument is ignored; however, some imple‐ mentations require fd to be -1 if MAP_ANONYMOUS (or MAP_ANON) is specified, and portable applications should ensure this. The This patch follows this advise. Tested on x86_64-pc-linux-gnu, amd64-pc-solaris2.11 and sparcv9-sun-solaris2.11. Differential Revision: https://reviews.llvm.org/D68455 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@375490 91177308-0d34-0410-b5e6-96231b3b80d8
* [hwasan] Workaround unwinder issues in try-catch test.Evgeniy Stepanov2019-10-211-4/+5
| | | | | | | | | | Android links the unwinder library to every DSO. The problem is, unwinder has global state, and hwasan implementation of personality function wrapper happens to rub it the wrong way. Switch the test to static libc++ as a temporary workaround. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@375471 91177308-0d34-0410-b5e6-96231b3b80d8
* [profile] Use -fPIC -shared in a test instead of -dynamiclibVedant Kumar2019-10-191-1/+1
| | | | | | | This is more portable than -dynamiclib. Also, fix the path to an input file that broke when the test was moved in r375315. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@375317 91177308-0d34-0410-b5e6-96231b3b80d8
* [profile] Disable instrprof-get-filename-merge-mode.c on WindowsVedant Kumar2019-10-191-0/+0
| | | | | | | | The Windows bots are failing with: clang: warning: argument unused during compilation: '-dynamiclib' [-Wunused-command-line-argument] git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@375315 91177308-0d34-0410-b5e6-96231b3b80d8
* [profile] Do not cache __llvm_profile_get_filename resultVedant Kumar2019-10-183-8/+23
| | | | | | | | | | | | | | | | | When the %m filename pattern is used, the filename is unique to each image, so the cached value is wrong. It struck me that the full filename isn't something that's recomputed often, so perhaps it doesn't need to be cached at all. David Li pointed out we can go further and just hide lprofCurFilename. This may regress workflows that depend on using the set-filename API to change filenames across all loaded DSOs, but this is expected to be very rare. rdar://55137071 Differential Revision: https://reviews.llvm.org/D69137 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@375301 91177308-0d34-0410-b5e6-96231b3b80d8
* [hwasan] Remove system allocator fallback.Evgeniy Stepanov2019-10-181-54/+0
| | | | | | | | | | | | | | | | Summary: This has been an experiment with late malloc interposition, made possible by a non-standard feature of the Android dynamic loader. Reviewers: pcc, mmalcomson Subscribers: srhines, #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D69199 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@375296 91177308-0d34-0410-b5e6-96231b3b80d8
* [Builtins] Downgrade duplicate source file warning from a fatal error to a ↵Dan Liew2019-10-171-1/+3
| | | | | | | | | | | | | | | | | | | warning. This is a follow up to r375150 to unbreak the `clang-ppc64be-linux` bot. The commit caused running the tests to fail due to ``` llvm-lit: /home/buildbots/ppc64be-clang-multistage-test/clang-ppc64be-multistage/llvm/projects/compiler-rt/test/builtins/Unit/lit.cfg.py:116: fatal: builtins_source_features contains duplicates: ['librt_has_divtc3'] ``` This commit should be reverted once the build system bug for powerpc is fixed. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@375162 91177308-0d34-0410-b5e6-96231b3b80d8
* [Builtins] Provide a mechanism to selectively disable tests based on whether ↵Dan Liew2019-10-17180-0/+228
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | an implementation is provided by a builtin library. Summary: If a platform removes some builtin implementations (e.g. via the Darwin-excludes mechanism) then this can lead to test failures because the test expects an implementation to be available. To solve this lit features are added for each configuration based on which sources are included in the builtin library. The features are of the form `librt_has_<name>` where `<name>` is the name of the source file with the file extension removed. This handles C and assembly sources. With the lit features in place it is possible to make certain tests require them. Example: ``` REQUIRES: librt_has_comparedf2 ``` All top-level tests in `test/builtins/Unit` (i.e. not under `arm`, `ppc`, and `riscv`) have been annotated with the appropriate `REQUIRES: librt_has_*` statement. rdar://problem/55520987 Reviewers: beanz, steven_wu, arphaman, dexonsmith, phosek, thakis Subscribers: mgorny, #sanitizers, llvm-commits Tags: #llvm, #sanitizers Differential Revision: https://reviews.llvm.org/D68064 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@375150 91177308-0d34-0410-b5e6-96231b3b80d8
* [asan] Update Windows test expectations for LLVM's MS demanglerReid Kleckner2019-10-172-4/+4
| | | | | | | | After r375041 llvm-symbolizer uses it for demangling instead of UnDecorateSymbolName. LLVM puts spaces after commas while Microsoft does not. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@375147 91177308-0d34-0410-b5e6-96231b3b80d8
* CFI: wrong type passed to llvm.type.test with multiple inheritance ↵Dmitry Mikulin2019-10-151-0/+38
| | | | | | | | devirtualization. Differential Revision: https://reviews.llvm.org/D67985 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@374909 91177308-0d34-0410-b5e6-96231b3b80d8
* Add a missing include in test.Evgeniy Stepanov2019-10-101-0/+1
| | | | | | A fix for r373993. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@374448 91177308-0d34-0410-b5e6-96231b3b80d8
* Reland "[ASan] Do not misrepresent high value address dereferences as null ↵Julian Lettner2019-10-101-0/+50
| | | | | | | | | | | | | | | | | | | | | | | | | | | | dereferences" Updated: Removed offending TODO comment. Dereferences with addresses above the 48-bit hardware addressable range produce "invalid instruction" (instead of "invalid access") hardware exceptions (there is no hardware address decoding logic for those bits), and the address provided by this exception is the address of the instruction (not the faulting address). The kernel maps the "invalid instruction" to SEGV, but fails to provide the real fault address. Because of this ASan lies and says that those cases are null dereferences. This downgrades the severity of a found bug in terms of security. In the ASan signal handler, we can not provide the real faulting address, but at least we can try not to lie. rdar://50366151 Reviewed By: vitalybuka Differential Revision: https://reviews.llvm.org/D68676 llvm-svn: 374265 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@374384 91177308-0d34-0410-b5e6-96231b3b80d8
* [Sanitizers] Fix getrandom testDavid Carlier2019-10-101-1/+1
| | | | git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@374333 91177308-0d34-0410-b5e6-96231b3b80d8
* [Sanitizers] Porting getrandom/getentropy interceptors to FreeBSDDavid Carlier2019-10-101-4/+8
| | | | | | | | | | | | | - Available from 12.x branch, by the time it lands next year in FreeBSD tree, the 11.x's might be EOL. - Intentionally changed the getrandom test to C code as with 12.0 (might be fixed in CURRENT since), there is a linkage issue in C++ context. Reviewers: emaste, dim, vitalybuka Reviewed-By: vitalybuka Differential Revision: https://reviews.llvm.org/D68451 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@374315 91177308-0d34-0410-b5e6-96231b3b80d8
* [UBSan] Split nullptr-and-nonzero-offset-variable.c in another directionRoman Lebedev2019-10-102-51/+12
| | | | git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@374309 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert "[ASan] Do not misrepresent high value address dereferences as null ↵Russell Gallop2019-10-101-50/+0
| | | | | | | | | | dereferences" As it was breaking bots running sanitizer lint check This reverts r374265 (git b577efe4567f1f6a711ad36e1d17280dd1c4f009) git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@374308 91177308-0d34-0410-b5e6-96231b3b80d8
* [UBSan] Split nullptr-and-nonzero-offset-variable.cpp into C and C++ variantsRoman Lebedev2019-10-102-13/+42
| | | | | | I do not understand the BB failire, it fully passes locally. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@374306 91177308-0d34-0410-b5e6-96231b3b80d8
* [UBSan] Revisit nullptr-and-nonzero-offset-variable.cpp test to hopefully ↵Roman Lebedev2019-10-101-7/+7
| | | | | | make it pass on sanitizer-windows BB git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@374298 91177308-0d34-0410-b5e6-96231b3b80d8
* [UBSan][clang][compiler-rt] Applying non-zero offset to nullptr is undefined ↵Roman Lebedev2019-10-106-6/+152
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | behaviour Summary: Quote from http://eel.is/c++draft/expr.add#4: ``` 4 When an expression J that has integral type is added to or subtracted from an expression P of pointer type, the result has the type of P. (4.1) If P evaluates to a null pointer value and J evaluates to 0, the result is a null pointer value. (4.2) Otherwise, if P points to an array element i of an array object x with n elements ([dcl.array]), the expressions P + J and J + P (where J has the value j) point to the (possibly-hypothetical) array element i+j of x if 0≤i+j≤n and the expression P - J points to the (possibly-hypothetical) array element i−j of x if 0≤i−j≤n. (4.3) Otherwise, the behavior is undefined. ``` Therefore, as per the standard, applying non-zero offset to `nullptr` (or making non-`nullptr` a `nullptr`, by subtracting pointer's integral value from the pointer itself) is undefined behavior. (*if* `nullptr` is not defined, i.e. e.g. `-fno-delete-null-pointer-checks` was *not* specified.) To make things more fun, in C (6.5.6p8), applying *any* offset to null pointer is undefined, although Clang front-end pessimizes the code by not lowering that info, so this UB is "harmless". Since rL369789 (D66608 `[InstCombine] icmp eq/ne (gep inbounds P, Idx..), null -> icmp eq/ne P, null`) LLVM middle-end uses those guarantees for transformations. If the source contains such UB's, said code may now be miscompiled. Such miscompilations were already observed: * https://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20190826/687838.html * https://github.com/google/filament/pull/1566 Surprisingly, UBSan does not catch those issues ... until now. This diff teaches UBSan about these UB's. `getelementpointer inbounds` is a pretty frequent instruction, so this does have a measurable impact on performance; I've addressed most of the obvious missing folds (and thus decreased the performance impact by ~5%), and then re-performed some performance measurements using my [[ https://github.com/darktable-org/rawspeed | RawSpeed ]] benchmark: (all measurements done with LLVM ToT, the sanitizer never fired.) * no sanitization vs. existing check: average `+21.62%` slowdown * existing check vs. check after this patch: average `22.04%` slowdown * no sanitization vs. this patch: average `48.42%` slowdown Reviewers: vsk, filcab, rsmith, aaron.ballman, vitalybuka, rjmccall, #sanitizers Reviewed By: rsmith Subscribers: kristof.beyls, nickdesaulniers, nikic, ychen, dtzWill, xbolva00, dberris, arphaman, rupprecht, reames, regehr, llvm-commits, cfe-commits Tags: #clang, #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D67122 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@374293 91177308-0d34-0410-b5e6-96231b3b80d8
* [ASan] Do not misrepresent high value address dereferences as null dereferencesJulian Lettner2019-10-101-0/+50
| | | | | | | | | | | | | | | | | | | | | | Dereferences with addresses above the 48-bit hardware addressable range produce "invalid instruction" (instead of "invalid access") hardware exceptions (there is no hardware address decoding logic for those bits), and the address provided by this exception is the address of the instruction (not the faulting address). The kernel maps the "invalid instruction" to SEGV, but fails to provide the real fault address. Because of this ASan lies and says that those cases are null dereferences. This downgrades the severity of a found bug in terms of security. In the ASan signal handler, we can not provide the real faulting address, but at least we can try not to lie. rdar://50366151 Reviewed By: vitalybuka Differential Revision: https://reviews.llvm.org/D68676 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@374265 91177308-0d34-0410-b5e6-96231b3b80d8
* [sanitizer, NFC] Fix grammar in commentVitaly Buka2019-10-091-1/+1
| | | | git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@374223 91177308-0d34-0410-b5e6-96231b3b80d8
* [sanitizer] Disable signal_trap_handler on s390Vitaly Buka2019-10-091-0/+5
| | | | git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@374220 91177308-0d34-0410-b5e6-96231b3b80d8
* [sanitizer] Make signal_name a C testVitaly Buka2019-10-091-2/+3
| | | | git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@374213 91177308-0d34-0410-b5e6-96231b3b80d8
* [sanitizer] Use raise() in test and cover more signalsVitaly Buka2019-10-092-8/+19
| | | | git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@374211 91177308-0d34-0410-b5e6-96231b3b80d8
* [sanitizer] Fix crypt.cpp on Android againVitaly Buka2019-10-082-6/+3
| | | | git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@374125 91177308-0d34-0410-b5e6-96231b3b80d8
* [sanitizer] Fix crypt.cpp test on DarwinVitaly Buka2019-10-082-4/+7
| | | | git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@374115 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix `compiler_rt_logbf_test.c` test failure for Builtins-i386-darwin test suite.Dan Liew2019-10-081-3/+7
| | | | | | | | | | | | | | | | | | | | | | | Summary: It seems that compiler-rt's implementation and Darwin libm's implementation of `logbf()` differ when given a NaN with raised sign bit. Strangely this behaviour only happens with i386 Darwin libm. For x86_64 and x86_64h the existing compiler-rt implementation matched Darwin libm. To workaround this the `compiler_rt_logbf_test.c` has been modified to do a comparison on the `fp_t` type and if that fails check if both values are NaN. If both values are NaN they are equivalent and no error needs to be raised. rdar://problem/55565503 Reviewers: rupprecht, scanon, compnerd, echristo Subscribers: #sanitizers, llvm-commits Tags: #llvm, #sanitizers Differential Revision: https://reviews.llvm.org/D67999 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@374109 91177308-0d34-0410-b5e6-96231b3b80d8
* [sanitizer] Disable crypt*.cpp tests on AndroidVitaly Buka2019-10-082-5/+7
| | | | git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@374088 91177308-0d34-0410-b5e6-96231b3b80d8
* [sanitizer] Fix signal_trap_handler.cpp on androidVitaly Buka2019-10-081-6/+11
| | | | git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@374010 91177308-0d34-0410-b5e6-96231b3b80d8
* [msan] Add interceptors: crypt, crypt_r.Evgeniy Stepanov2019-10-082-0/+63
| | | | | | | | | | | | Reviewers: vitalybuka Subscribers: srhines, #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D68431 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@373993 91177308-0d34-0410-b5e6-96231b3b80d8
* [sanitizer] Print SIGTRAP for corresponding signalVitaly Buka2019-10-071-0/+8
| | | | | | | | | | | | Reviewers: eugenis, jfb Subscribers: #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D68603 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@373979 91177308-0d34-0410-b5e6-96231b3b80d8
* [tsan] Don't delay SIGTRAP handlerVitaly Buka2019-10-071-0/+29
| | | | | | | | | | | | Reviewers: eugenis, jfb Subscribers: #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D68604 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@373978 91177308-0d34-0410-b5e6-96231b3b80d8
* [compiler-rt] Remove O1 tests from signal_line.cppVitaly Buka2019-10-041-4/+0
| | | | | | It does not work on arm git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@373702 91177308-0d34-0410-b5e6-96231b3b80d8
* [compiler-rt] Fix signal_line.cpp testVitaly Buka2019-10-041-2/+2
| | | | | | r373682 committed wrong experimental version git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@373684 91177308-0d34-0410-b5e6-96231b3b80d8
* [compiler-rt] Remove O2, O3 from signal_line test for fix android testsVitaly Buka2019-10-041-11/+2
| | | | git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@373682 91177308-0d34-0410-b5e6-96231b3b80d8
* [compiler-rt] More optimization levels in signal_line.cpp testVitaly Buka2019-10-031-12/+13
| | | | git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@373642 91177308-0d34-0410-b5e6-96231b3b80d8
* [sanitizer_common] Disable onprint.cpp on Android.Matt Morehouse2019-10-021-0/+2
| | | | | | The test fails to find the written file on Android. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@373531 91177308-0d34-0410-b5e6-96231b3b80d8
* [compiler-rt] Use GetNextInstructionPc in signal handlersVitaly Buka2019-10-021-0/+36
| | | | | | | | | | | | | | | | | | Summary: All other stack trace callers assume that PC contains return address. HWAsan already use GetNextInstructionPc in similar code. PR43339 Reviewers: eugenis, kcc, jfb Subscribers: dexonsmith, dberris, #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D68313 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@373529 91177308-0d34-0410-b5e6-96231b3b80d8
* [sanitizer_common] Rename OnPrint to __sanitizer_on_print.Matt Morehouse2019-10-021-0/+31
| | | | | | | | | | | | | | | | | | Summary: https://reviews.llvm.org/D28596 exposed OnPrint in the global namespace, which can cause collisions with user-defined OnPrint() functions. Reviewers: vitalybuka, dvyukov Reviewed By: vitalybuka, dvyukov Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67987 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@373518 91177308-0d34-0410-b5e6-96231b3b80d8
* [CMake] Fix the value of `config.target_cflags` for non-macOS Apple ↵Dan Liew2019-10-014-50/+79
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | platforms. Attempt #3. 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 third 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. The second attempt (r363633) had to be reverted (r363779) due to a build failure. The failed build was using a modified Apple toolchain where the iOS simulator SDK was missing. This exposed a bug in the existing UBSan test generation code where it was assumed that `COMPILER_RT_ENABLE_IOS` implied that the toolchain supported both iOS and the iOS simulator. This is not true. This has been fixed by using the list `SANITIZER_COMMON_SUPPORTED_OS` for the list of supported Apple platforms for UBSan. For consistency with the other Sanitizers we also now intersect the list of architectures with UBSAN_SUPPORTED_ARCH. rdar://problem/50124489 Differential Revision: https://reviews.llvm.org/D61242 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@373405 91177308-0d34-0410-b5e6-96231b3b80d8
* [libFuzzer] Remove lazy counters.Matt Morehouse2019-10-011-3/+0
| | | | | | | | | | | | | | | | Summary: Lazy counters haven't improved performance for large fuzz targets. Reviewers: kcc Reviewed By: kcc Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D67476 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@373403 91177308-0d34-0410-b5e6-96231b3b80d8
* [msan] Intercept __getrlimit.Evgeniy Stepanov2019-09-301-0/+16
| | | | | | | | | | | | | | | | | | | | Summary: This interceptor is useful on its own, but the main purpose of this change is to intercept libpthread initialization on linux/glibc in order to run __msan_init before any .preinit_array constructors. We used to trigger on pthread_initialize_minimal -> getrlimit(), but that call has changed to __getrlimit at some point. Reviewers: vitalybuka, pcc Subscribers: jfb, #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D68168 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@373239 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert "[profile] Add a test dependency on cxx-headers"Vedant Kumar2019-09-271-1/+1
| | | | | | | | | | This reverts commit b539350f7d006b7d6f42c5c4b5715da87a52e5d8. See: http://lab.llvm.org:8011/builders/sanitizer-windows/builds/52140/steps/annotate/logs/stdio The cxx-headers target doesn't exist everywhere. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@373123 91177308-0d34-0410-b5e6-96231b3b80d8
* [profile] Mark instrprof-gcov-fork.test UNSUPPORTED on Darwin as wellVedant Kumar2019-09-271-0/+1
| | | | | | | | | | This test remains flaky everywhere, I think. We should consider deleting it and accompanying support code in GCOVProfiling: I've stopped short of doing that now as the gcov exec* tests appear to be stable. See the thread re: r347779. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@373121 91177308-0d34-0410-b5e6-96231b3b80d8
* [profile] Add a test dependency on cxx-headersVedant Kumar2019-09-271-1/+1
| | | | | | | This enables running profile runtime tests which #include <string>, etc. via just `check-profile`. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@373120 91177308-0d34-0410-b5e6-96231b3b80d8
* hwasan: Compatibility fixes for short granules.Peter Collingbourne2019-09-272-3/+10
| | | | | | | | | | | | | | | | | | | | | | | | | We can't use short granules with stack instrumentation when targeting older API levels because the rest of the system won't understand the short granule tags stored in shadow memory. Moreover, we need to be able to let old binaries (which won't understand short granule tags) run on a new system that supports short granule tags. Such binaries will call the __hwasan_tag_mismatch function when their outlined checks fail. We can compensate for the binary's lack of support for short granules by implementing the short granule part of the check in the __hwasan_tag_mismatch function. Unfortunately we can't do anything about inline checks, but I don't believe that we can generate these by default on aarch64, nor did we do so when the ABI was fixed. A new function, __hwasan_tag_mismatch_v2, is introduced that lets code targeting the new runtime avoid redoing the short granule check. Because tag mismatches are rare this isn't important from a performance perspective; the main benefit is that it introduces a symbol dependency that prevents binaries targeting the new runtime from running on older (i.e. incompatible) runtimes. Differential Revision: https://reviews.llvm.org/D68059 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@373035 91177308-0d34-0410-b5e6-96231b3b80d8
* [libFuzzer] [NFC] Fix grammar error with "it's"Mitch Phillips2019-09-261-1/+1
| | | | git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@372937 91177308-0d34-0410-b5e6-96231b3b80d8
* builtins test: Move clear_cache_test.c from a mprotect()ed global to a ↵Nico Weber2019-09-251-28/+21
| | | | | | | | | | | | | | | | | | mmap()ed variable ld64 in the macOS 10.15 SDK gives __DATA a maxprot of 3, meaning it can't be made executable at runtime by default. Change clear_cache_test.c to use mmap()ed data that's mapped as writable and executable from the beginning, instead of trying to mprotect()ing a __DATA variable as executable. This fixes the test on macOS with the 10.15 SDK. PR43407. Differential Revision: https://reviews.llvm.org/D67929 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@372849 91177308-0d34-0410-b5e6-96231b3b80d8
* [TSAN] Add read/write range interface functions with PCJoachim Protze2019-09-241-0/+40
| | | | | | | | | | Adding annotation function variants __tsan_write_range_pc and __tsan_read_range_pc to annotate ranged access to memory while providing a program counter for the access. Differential Revision: https://reviews.llvm.org/D66885 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@372730 91177308-0d34-0410-b5e6-96231b3b80d8
* [llvm-cov] NFC: Specify a specific C++ standard in the test.Artem Dergachev2019-09-241-3/+6
| | | | | | Makes life easier for downstream users with customized default standard. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@372674 91177308-0d34-0410-b5e6-96231b3b80d8
View Lorry Controller Status