summaryrefslogtreecommitdiff
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
* Fix lld detection in standalone compiler-rt.Evgeniy Stepanov2019-10-212-1/+2
| | | | | | | | | | | | | | | | | Summary: Right now all hwasan tests on Android are silently disabled because they require "has_lld" and standalone compiler-rt can not (and AFAIK was never able to) set it. Reviewers: pcc, dyung Subscribers: dberris, mgorny, #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D69196 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@375472 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-185-18/+39
| | | | | | | | | | | | | | | | | 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: Add missing SANITIZER_INTERFACE_ATTRIBUTE on ↵Peter Collingbourne2019-10-181-4/+7
| | | | | | | | __hwasan_personality_wrapper. Differential Revision: https://reviews.llvm.org/D69201 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@375298 91177308-0d34-0410-b5e6-96231b3b80d8
* [hwasan] Remove system allocator fallback.Evgeniy Stepanov2019-10-184-91/+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
* Update global_symbols.txt.Peter Collingbourne2019-10-181-0/+1
| | | | git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@375284 91177308-0d34-0410-b5e6-96231b3b80d8
* scudo: Update TLS_SLOT_SANITIZER value.Peter Collingbourne2019-10-181-1/+1
| | | | | | | | | | Android now allocates only 8 fixed TLS slots. Somehow we were getting away with using a non-existent slot until now, but in some cases the TLS slots were being placed at the end of a page, which led to a segfault at startup. Differential Revision: https://reviews.llvm.org/D69191 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@375276 91177308-0d34-0410-b5e6-96231b3b80d8
* [Arm][libsanitizer] Fix arm libsanitizer failure with bleeding edge glibcSjoerd Meijer2019-10-181-1/+4
| | | | | | | | | | | | | | | | Glibc has recently introduced changed to the mode field in ipc_perm in commit 2f959dfe849e0646e27403f2e4091536496ac0f0. For Arm this means that the mode field no longer has the same size. This causes an assert failure against libsanitizer's internal copy of ipc_perm. Since this change can't be easily detected I am adding arm to the list of targets that are excluded from this check. Patch by: Tamar Christina Differential Revision: https://reviews.llvm.org/D69104 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@375220 91177308-0d34-0410-b5e6-96231b3b80d8
* libhwasan initialisation include kernel syscall ABI relaxationEvgeniy Stepanov2019-10-173-0/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Until now AArch64 development has been on patched kernels that have an always on relaxed syscall ABI where tagged pointers are accepted. The patches that have gone into the mainline kernel rely on each process opting in to this relaxed ABI. This commit adds code to choose that ABI into __hwasan_init. The idea has already been agreed with one of the hwasan developers (http://lists.llvm.org/pipermail/llvm-dev/2019-September/135328.html). The patch ignores failures of `EINVAL` for Android, since there are older versions of the Android kernel that don't require this `prctl` or even have the relevant values. Avoiding EINVAL will let the library run on them. I've tested this on an AArch64 VM running a kernel that requires this prctl, having compiled both with clang and gcc. Patch by Matthew Malcomson. Reviewers: eugenis, kcc, pcc Reviewed By: eugenis Subscribers: srhines, kristof.beyls, #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D68794 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@375166 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
* Revert [Sanitizers] Add support for RISC-V 64-bitSam Elliott2019-10-176-20/+9
| | | | | | This reverts r375132 (git commit 00bbe990c5d4472d5413479a539b3d6edbb3ca7a) git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@375136 91177308-0d34-0410-b5e6-96231b3b80d8
* [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 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@375132 91177308-0d34-0410-b5e6-96231b3b80d8
* [mips] [builtins] Remove clear_mips_cacheZoran Jovanovic2019-10-171-50/+0
| | | | | | | Differential Revision: https://reviews.llvm.org/D69021 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@375110 91177308-0d34-0410-b5e6-96231b3b80d8
* [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 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@374977 91177308-0d34-0410-b5e6-96231b3b80d8
* Revert "[ASan] Refine diagnoses messages"Julian Lettner2019-10-161-1/+2
| | | | | | This reverts commit 4d1ecadda59ce82e5fa6e28dd15bf794eee88363. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@374965 91177308-0d34-0410-b5e6-96231b3b80d8
* [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. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@374959 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
* 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) git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@374868 91177308-0d34-0410-b5e6-96231b3b80d8
* [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 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@374612 91177308-0d34-0410-b5e6-96231b3b80d8
* Fix check-interception link error in compiler-rt debug modeReid Kleckner2019-10-101-1/+4
| | | | git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@374472 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-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 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
* Fix sanitizer lint check after r374315Russell Gallop2019-10-101-1/+2
| | | | git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@374321 91177308-0d34-0410-b5e6-96231b3b80d8
* [UBSan] Appease linterRoman Lebedev2019-10-101-2/+4
| | | | git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@374316 91177308-0d34-0410-b5e6-96231b3b80d8
* [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 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-107-90/+6
| | | | | | | | | | 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-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 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-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 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@374265 91177308-0d34-0410-b5e6-96231b3b80d8
* [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 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@374258 91177308-0d34-0410-b5e6-96231b3b80d8
* [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 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@374228 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
* [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 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@374173 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
* [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 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@374070 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
View Lorry Controller Status