summaryrefslogtreecommitdiffstats
path: root/compiler-rt
Commit message (Collapse)AuthorAgeFilesLines
...
* [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 llvm-svn: 375150
* [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. llvm-svn: 375147
* Revert [Sanitizers] Add support for RISC-V 64-bitSam Elliott2019-10-176-20/+9
| | | | | | This reverts r375132 (git commit 00bbe990c5d4472d5413479a539b3d6edbb3ca7a) llvm-svn: 375136
* [Sanitizers] Add support for RISC-V 64-bitSam Elliott2019-10-176-9/+20
| | | | | | | | | | | | | | | | | | | Summary: This has been tested with gcc trunk on openSUSE Tumbleweed on the HiFive Unleashed. Patch by Andreas Schwab (schwab) Reviewers: luismarques Reviewed By: luismarques Subscribers: mhorne, emaste, luismarques, asb, mgorny, fedor.sergeev, simoncook, kito-cheng, shiva0217, rogfer01, rkruppe, lenary, s.egerton, #sanitizers, llvm-commits Tags: #llvm, #sanitizers Differential Revision: https://reviews.llvm.org/D66870 llvm-svn: 375132
* [mips] [builtins] Remove clear_mips_cacheZoran Jovanovic2019-10-171-50/+0
| | | | | | Differential Revision: https://reviews.llvm.org/D69021 llvm-svn: 375110
* [CMake] Disable building all Darwin libraries (except builtins) for macOS ↵Dan Liew2019-10-161-1/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | i386 when the SDK is >= 10.15. Summary: In the macOS 10.15 SDK the ability to link i386 binaries was removed and in the corresponding OS it is not possible to run macOS i386 binaries. The consequence of these changes meant that targets like `check-asan` would fail because: * Unit tests could not be linked for i386 * Lit tests for i386 would fail due to not being able to execute compiled binaries. The simplest fix to this is to simply disable building for i386 for macOS when using the 10.15 SDK (or newer). This disables building the i386 slice for most compiler-rt libraries and consequently disables the unit and lit tests for macOS i386. Note that because the `DARWIN_osx_ARCHS` CMake variable is a cache variable this patch will have no affect on existing builds unless the existing cache variable is deleted. The simplest way to deal with this is delete existing builds and just do a fresh configure. Note this should not affect the builtins which are managed with the `DARWIN_osx_BUILTIN_ARCHS` CMake cache variable. For those who wish to force using a particular set of architectures when using newer SDKs passing `-DDARWIN_osx_ARCHS=i386;x86_64;x86_64h` to CMake should provide a usable (but completely unsupported) workaround. rdar://problem/55668535 rdar://problem/47939978 Reviewers: kubamracek, yln, azhar, kcc, dvyukov, vitalybuka, cryptoad, eugenis, thakis, phosek Subscribers: mgorny, #sanitizers, llvm-commits Tags: #llvm, #sanitizers Differential Revision: https://reviews.llvm.org/D68292 llvm-svn: 374977
* Revert "[ASan] Refine diagnoses messages"Julian Lettner2019-10-161-1/+2
| | | | | | This reverts commit 4d1ecadda59ce82e5fa6e28dd15bf794eee88363. llvm-svn: 374965
* [ASan] Refine diagnoses messagesJulian Lettner2019-10-161-2/+1
| | | | | | | The provided PC is not reliable in every case, so don't suggest something that does not make sense. llvm-svn: 374959
* 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 llvm-svn: 374909
* tsan: fix Go ppc64le buildDmitry Vyukov2019-10-151-0/+2
| | | | | | | | This #define is in the non-Go ppc64le build but not in the Go build. Reviewed-in: https://reviews.llvm.org/D68046 Author: randall77 (Keith Randall) llvm-svn: 374868
* [libFuzzer] Don't prefix absolute paths in fuchsia.Jake Ehrlich2019-10-111-5/+6
| | | | | | | | | | | | | | | | | | | | | | | The ExecuteCommand function in fuchsia used to prefix the getOutputFile for each command run with the artifact_prefix flag if it was available, because fuchsia components don't have a writable working directory. However, if a file with a global path is provided, fuchsia should honor that. An example of this is using the global /tmp directory to store stuff. In fuchsia it ended up being translated to data///tmp, whereas we want to make sure it is using /tmp (which is available to components using the isolated-temp feature). To test this I made the change, compiled fuchsia with this toolchain and ran a fuzzer with the -fork=1 flag (that mode makes use of the /tmp directory). I also tested that normal fuzzing workflow was not affected by this. Author: charco (Marco Vanotti) Differential Revision: https://reviews.llvm.org/D68774 llvm-svn: 374612
* Fix check-interception link error in compiler-rt debug modeReid Kleckner2019-10-101-1/+4
| | | | llvm-svn: 374472
* Add a missing include in test.Evgeniy Stepanov2019-10-101-0/+1
| | | | | | A fix for r373993. llvm-svn: 374448
* Reland "[ASan] Do not misrepresent high value address dereferences as null ↵Julian Lettner2019-10-107-6/+90
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 llvm-svn: 374384
* [Sanitizers] Fix getrandom testDavid Carlier2019-10-101-1/+1
| | | | llvm-svn: 374333
* Fix sanitizer lint check after r374315Russell Gallop2019-10-101-1/+2
| | | | llvm-svn: 374321
* [UBSan] Appease linterRoman Lebedev2019-10-101-2/+4
| | | | llvm-svn: 374316
* [Sanitizers] Porting getrandom/getentropy interceptors to FreeBSDDavid Carlier2019-10-103-5/+26
| | | | | | | | | | | | | - 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 llvm-svn: 374315
* [UBSan] Split nullptr-and-nonzero-offset-variable.c in another directionRoman Lebedev2019-10-102-51/+12
| | | | llvm-svn: 374309
* Revert "[ASan] Do not misrepresent high value address dereferences as null ↵Russell Gallop2019-10-107-90/+6
| | | | | | | | | | dereferences" As it was breaking bots running sanitizer lint check This reverts r374265 (git b577efe4567f1f6a711ad36e1d17280dd1c4f009) llvm-svn: 374308
* [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. llvm-svn: 374306
* [UBSan] Revisit nullptr-and-nonzero-offset-variable.cpp test to hopefully ↵Roman Lebedev2019-10-101-7/+7
| | | | | | make it pass on sanitizer-windows BB llvm-svn: 374298
* [UBSan][clang][compiler-rt] Applying non-zero offset to nullptr is undefined ↵Roman Lebedev2019-10-109-9/+177
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 llvm-svn: 374293
* [ASan] Do not misrepresent high value address dereferences as null dereferencesJulian Lettner2019-10-107-6/+90
| | | | | | | | | | | | | | | | | | | | | | 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
* [sanitizer_common] Remove OnPrint from Go build.Matt Morehouse2019-10-091-6/+0
| | | | | | | | | | | | | | | | Summary: Go now uses __sanitizer_on_print instead. Reviewers: vitalybuka, dvyukov Reviewed By: vitalybuka Subscribers: llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68621 llvm-svn: 374258
* [libFuzzer] Fix Alarm callback in fuchsia.Jake Ehrlich2019-10-091-2/+2
| | | | | | | | | | | | | | | | This patch adds an #if macro to skip the InFuzzingThread() comparison for fuchsia, similar to what it is done for Windows and NetBSD. In fuchsia, the alarm callback runs in a separate thread[0], making it fail the comparison InFuzzingThread(), breaking the -timeout flag. [0]: https://github.com/llvm/llvm-project/blob/master/compiler-rt/lib/fuzzer/FuzzerUtilFuchsia.cpp#L323 Author: charco (aka Marco Vanotti) Differential Revision: https://reviews.llvm.org/D68166 llvm-svn: 374228
* [sanitizer, NFC] Fix grammar in commentVitaly Buka2019-10-091-1/+1
| | | | llvm-svn: 374223
* [sanitizer] Disable signal_trap_handler on s390Vitaly Buka2019-10-091-0/+5
| | | | llvm-svn: 374220
* [sanitizer] Make signal_name a C testVitaly Buka2019-10-091-2/+3
| | | | llvm-svn: 374213
* [sanitizer] Use raise() in test and cover more signalsVitaly Buka2019-10-092-8/+19
| | | | llvm-svn: 374211
* [scudo][standalone] Get statistics in a char bufferKostya Kortchinsky2019-10-0914-69/+145
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Following up on D68471, this CL introduces some `getStats` APIs to gather statistics in char buffers (`ScopedString` really) instead of printing them out right away. Ultimately `printStats` will just output the buffer, but that allows us to potentially do some work on the intermediate buffer, and can be used for a `mallocz` type of functionality. This allows us to pretty much get rid of all the `Printf` calls around, but I am keeping the function in for debugging purposes. This changes the existing tests to use the new APIs when required. I will add new tests as suggested in D68471 in another CL. Reviewers: morehouse, hctim, vitalybuka, eugenis, cferris Reviewed By: morehouse Subscribers: delcypher, #sanitizers, llvm-commits Tags: #llvm, #sanitizers Differential Revision: https://reviews.llvm.org/D68653 llvm-svn: 374173
* [sanitizer] Fix crypt.cpp on Android againVitaly Buka2019-10-082-6/+3
| | | | llvm-svn: 374125
* [sanitizer] Fix crypt.cpp test on DarwinVitaly Buka2019-10-082-4/+7
| | | | llvm-svn: 374115
* 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 llvm-svn: 374109
* [sanitizer] Disable crypt*.cpp tests on AndroidVitaly Buka2019-10-082-5/+7
| | | | llvm-svn: 374088
* [builtins] Unbreak build on FreeBSD armv7 after D60351David Carlier2019-10-082-3/+9
| | | | | | | | | | | | headers include reordering. Reviewers: phosek, echristo Reviewed-By: phosek Differential Revsion: https://reviews.llvm.org/D68045 llvm-svn: 374070
* [sanitizer] Fix signal_trap_handler.cpp on androidVitaly Buka2019-10-081-6/+11
| | | | llvm-svn: 374010
* [msan] Add interceptors: crypt, crypt_r.Evgeniy Stepanov2019-10-086-0/+105
| | | | | | | | | | | | Reviewers: vitalybuka Subscribers: srhines, #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D68431 llvm-svn: 373993
* [tsan, go] fix Go windows buildVitaly Buka2019-10-072-0/+18
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: Don't use weak exports when building tsan into a shared library for Go. gcc can't handle the pragmas used to make the weak references. Include files that have been added since the last update to build.bat. (We should really find a better way to list all the files needed.) Add windows version defines (WINVER and _WIN32_WINNT) to get AcquireSRWLockExclusive and ReleaseSRWLockExclusive defined. Define GetProcessMemoryInfo to use the kernel32 version. This is kind of a hack, the windows header files should do this translation for us. I think we're not in the right family partition (we're using Desktop, but that translation only happens for App and System partitions???), but hacking the family partition seems equally gross and I have no idea what the consequences of that might be. Patch by Keith Randall. Reviewers: dvyukov, vitalybuka Reviewed By: vitalybuka Subscribers: jfb, delcypher, #sanitizers, llvm-commits Tags: #llvm, #sanitizers Differential Revision: https://reviews.llvm.org/D68599 llvm-svn: 373984
* [tsan, go] break commands into multiple linesVitaly Buka2019-10-071-3/+55
| | | | | | | | | | | | | | Summary: Patch by Keith Randall. Reviewers: dvyukov, vitalybuka Subscribers: delcypher, jfb, #sanitizers, llvm-commits Tags: #llvm, #sanitizers Differential Revision: https://reviews.llvm.org/D68596 llvm-svn: 373983
* [sanitizer] Print SIGTRAP for corresponding signalVitaly Buka2019-10-072-0/+10
| | | | | | | | | | | | Reviewers: eugenis, jfb Subscribers: #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D68603 llvm-svn: 373979
* [tsan] Don't delay SIGTRAP handlerVitaly Buka2019-10-072-4/+34
| | | | | | | | | | | | Reviewers: eugenis, jfb Subscribers: #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D68604 llvm-svn: 373978
* [scudo][standalone] Correct releaseToOS behaviorKostya Kortchinsky2019-10-073-27/+67
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: There was an issue in `releaseToOSMaybe`: one of the criteria to decide if we should proceed with the release was wrong. Namely: ``` const uptr N = Sci->Stats.PoppedBlocks - Sci->Stats.PushedBlocks; if (N * BlockSize < PageSize) return; // No chance to release anything. ``` I meant to check if the amount of bytes in the free list was lower than a page, but this actually checks if the amount of **in use** bytes was lower than a page. The correct code is: ``` const uptr BytesInFreeList = Region->AllocatedUser - (Region->Stats.PoppedBlocks - Region->Stats.PushedBlocks) * BlockSize; if (BytesInFreeList < PageSize) return 0; // No chance to release anything. ``` Consequences of the bug: - if a class size has less than a page worth of in-use bytes (allocated or in a cache), reclaiming would not occur, whatever the amount of blocks in the free list; in real world scenarios this is unlikely to happen and be impactful; - if a class size had less than a page worth of free bytes (and enough in-use bytes, etc), then reclaiming would be attempted, with likely no result. This means the reclaiming was overzealous at times. I didn't have a good way to test for this, so I changed the prototype of the function to return the number of bytes released, allowing to get the information needed. The test added fails with the initial criteria. Another issue is that `ReleaseToOsInterval` can actually be 0, meaning we always try to release (side note: it's terrible for performances). so change a `> 0` check to `>= 0`. Additionally, decrease the `CanRelease` threshold to `PageSize / 32`. I still have to make that configurable but I will do it at another time. Finally, rename some variables in `printStats`: I feel like "available" was too ambiguous, so change it to "total". Reviewers: morehouse, hctim, eugenis, vitalybuka, cferris Reviewed By: morehouse Subscribers: delcypher, #sanitizers, llvm-commits Tags: #llvm, #sanitizers Differential Revision: https://reviews.llvm.org/D68471 llvm-svn: 373930
* [scudo][standalone] Make malloc_info return a minimal XMLKostya Kortchinsky2019-10-043-4/+16
| | | | | | | | | | | | | | | | | | | | | Summary: Initially, our malloc_info was returning ENOTSUP, but Android would rather have it return successfully and write a barebone XML to the stream, so we will oblige. Add an associated test. Reviewers: cferris, morehouse, hctim, eugenis, vitalybuka Reviewed By: morehouse Subscribers: delcypher, #sanitizers, llvm-commits Tags: #llvm, #sanitizers Differential Revision: https://reviews.llvm.org/D68427 llvm-svn: 373754
* [compiler-rt] Remove O1 tests from signal_line.cppVitaly Buka2019-10-041-4/+0
| | | | | | It does not work on arm llvm-svn: 373702
* [compiler-rt] Fix signal_line.cpp testVitaly Buka2019-10-041-2/+2
| | | | | | r373682 committed wrong experimental version llvm-svn: 373684
* [compiler-rt] Remove O2, O3 from signal_line test for fix android testsVitaly Buka2019-10-041-11/+2
| | | | llvm-svn: 373682
* compiler-rt: use __GLIBC_PREREQ for SANITIZER_INTERCEPT_GETRANDOMVitaly Buka2019-10-041-2/+2
| | | | | | | | | | | | | | Summary: Fixes https://github.com/google/oss-fuzz/issues/2836 Reviewers: eugenis Subscribers: dberris, #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D68178 llvm-svn: 373681
* [compiler-rt] More optimization levels in signal_line.cpp testVitaly Buka2019-10-031-12/+13
| | | | llvm-svn: 373642
* compiler-rt: move all __GLIBC_PREREQ into own header fileVitaly Buka2019-10-035-19/+38
| | | | | | | | | | | | Reviewers: eugenis Subscribers: dberris, #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D68177 llvm-svn: 373632
OpenPOWER on IntegriCloud