summaryrefslogtreecommitdiffstats
path: root/compiler-rt/test
Commit message (Collapse)AuthorAgeFilesLines
...
* [builtins] Implement rounding mode support for i386/x86_64Yi Kong2019-11-182-2/+4
| | | | Differential Revision: https://reviews.llvm.org/D69870
* [ASan] Mark test as UNSUPPORTED for iOS simulatorJulian Lettner2019-11-181-0/+1
| | | | | | coverage-fork.cpp uses `fork()` which requires additional permissions in the iOS simulator sandbox. We cannot use `sandbox-exec` to grant these permissions since this is a Posix (not Darwin) test.
* [GCOV] Skip artificial functions from being emittedAlexandre Ganea2019-11-151-3/+0
| | | | | | | | This is a patch to support D66328, which was reverted until this lands. Enable a compiler-rt test that used to fail previously with D66328. Differential Revision: https://reviews.llvm.org/D67283
* [SanitizerCommon] Print the current value of options when printing out help.Dan Liew2019-11-141-2/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Previously it wasn't obvious what the default value of various sanitizer options were. A very close approximation of the "default values" for the options are the current value of the options at the time of printing the help output. In the case that no other options are provided then the current values are the default values (apart from `help`). ``` ASAN_OPTIONS=help=1 ./program ``` This patch causes the current option values to be printed when the `help` output is enabled. The original intention for this patch was to append `(Default: <value>)` to an option's help text. However because this is technically wrong (and misleading) I've opted to append `(Current Value: <value>)` instead. When trying to implement a way of displaying the default value of the options I tried another solution where the default value used in `*.inc` files were used to create compile time strings that where used when printing the help output. This solution was not satisfactory for several reasons: * Stringifying the default values with the preprocessor did not work very well in several cases. Some options contain boolean operators which no amount of macro expansion can get rid of. * It was much more invasive than this patch. Every sanitizer had to be changed. * The settings of `__<sanitizer>_default_options()` are ignored. For those reasons I opted for the solution in this patch. rdar://problem/42567204 Reviewers: kubamracek, yln, kcc, dvyukov, vitalybuka, cryptoad, eugenis, samsonov Subscribers: #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D69546
* Fix include guard and properly order __deregister_frame_info.Sterling Augustine2019-11-121-1/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch fixes two problems with the crtbegin.c as written: 1. In do_init, register_frame_info is not guarded by a #define, but in do_fini, deregister_frame_info is guarded by #ifndef CRT_HAS_INITFINI_ARRAY. Thus when CRT_HAS_INITFINI_ARRAY is not defined, frames are registered but then never deregistered. The frame registry mechanism builds a linked-list from the .so's static variable do_init.object, and when the .so is unloaded, this memory becomes invalid and should be deregistered. Further, libgcc's crtbegin treats the frame registry as independent from the initfini array mechanism. This patch fixes this by adding a new #define, "EH_USE_FRAME_INFO_REGISTRY", which is set by the cmake option COMPILER_RT_CRT_USE_EH_FRAME_REGISTRY Currently, do_init calls register_frame_info, and then calls the binary's constructors. This allows constructors to safely use libunwind. However, do_fini calls deregister_frame_info and then calls the binary's destructors. This prevents destructors from safely using libunwind. This patch also switches that ordering, so that destructors can safely use libunwind. As it happens, this is a fairly common scenario for thread sanitizer.
* Reland "[compiler-rt] Fix tests after 03b84e4f6d0"Jan Korous2019-11-082-2/+2
| | | | This reverts commit d6be9273c6035c07b25dd1494f76cd61d523b878.
* [PowerPC][compiler-rt][builtins]Fix __fixunstfti builtin on PowerPCLei Huang2019-11-081-8/+650
| | | | | | | | | | | __fixunstfti converts a long double (IBM double-double) to an unsigned 128 bit integer. This patch enables it to handle a previously unhandled case in which a negative low double may impact the result of the conversion. Collaborated with @masoud.ataei and @renenkel. Patch By: Baptiste Saleil Differential Revision: https://reviews.llvm.org/D69193
* Revert "[compiler-rt] Fix tests after 03b84e4f6d0"Jeremy Morse2019-11-082-2/+2
| | | | | | This reverts commit bdeb2724f0aa9c518f94d998d24d8620a1e88727. (Reverting 03b84e4f6d0, so this must come out as well)
* [compiler-rt] Fix tests after 03b84e4f6d0Jan Korous2019-11-072-2/+2
| | | | | | | Fallout from: [clang] Report sanitizer blacklist as a dependency in cc1 Default blacklists are now passed via -fsanitize-system-blacklist from driver to cc1.
* [compiler-rt] [msan] Support POSIX iconv(3) on NetBSD 9.99.17+Kamil Rytarowski2019-11-041-1/+10
| | | | Fixes build of test.
* [profile] Add a mode to continuously sync counter updates to a fileVedant Kumar2019-10-317-0/+319
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add support for continuously syncing profile counter updates to a file. The motivation for this is that programs do not always exit cleanly. On iOS, for example, programs are usually killed via a signal from the OS. Running atexit() handlers after catching a signal is unreliable, so some method for progressively writing out profile data is necessary. The approach taken here is to mmap() the `__llvm_prf_cnts` section onto a raw profile. To do this, the linker must page-align the counter and data sections, and the runtime must ensure that counters are mapped to a page-aligned offset within a raw profile. Continuous mode is (for the moment) incompatible with the online merging mode. This limitation is lifted in https://reviews.llvm.org/D69586. Continuous mode is also (for the moment) incompatible with value profiling, as I'm not sure whether there is interest in this and the implementation may be tricky. As I have not been able to test extensively on non-Darwin platforms, only Darwin support is included for the moment. However, continuous mode may "just work" without modification on Linux and some UNIX-likes. AIUI the default value for the GNU linker's `--section-alignment` flag is set to the page size on many systems. This appears to be true for LLD as well, as its `no_nmagic` option is on by default. Continuous mode will not "just work" on Fuchsia or Windows, as it's not possible to mmap() a section on these platforms. There is a proposal to add a layer of indirection to the profile instrumentation to support these platforms. rdar://54210980 Differential Revision: https://reviews.llvm.org/D68351
* [profile] Clean up stale raw profiles in instrprof-write-file.cVedant Kumar2019-10-311-0/+1
|
* [asan] Provide an interface to update an allocation stack trace.Evgenii Stepanov2019-10-311-0/+19
| | | | | | | | | | | | | | Summary: Sometimes an allocation stack trace is not very informative. Provide a way to replace it with a stack trace of the user's choice. Reviewers: pcc, kcc Subscribers: #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D69208
* Revert "[Builtins] Downgrade duplicate source file warning from a fatal ↵Dan Liew2019-10-301-3/+1
| | | | | | | | | error to a warning." This reverts commit dc748816e2aec8941d63f8ad07fb82aff6be8af7. Now that 8ea148dc0cbff33ac3c80cf4273991465479a01e has landed it should be safe to turning the warning back into a fatal error.
* [sanitizer_common] Create max_allocation_size_mb flag.Matt Morehouse2019-10-301-0/+127
| | | | | | | | | | | | | | | | | Summary: The flag allows the user to specify a maximum allocation size that the sanitizers will honor. Any larger allocations will return nullptr or crash depending on allocator_may_return_null. Reviewers: kcc, eugenis Reviewed By: kcc, eugenis Subscribers: #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D69576
* [compiler-rt] libhwasan interceptor ABI intercept longjmp/setjmpDavid Tellenbach2019-10-301-0/+39
| | | | | | | | | | | | | | | | | | | | | | Summary: The hwasan interceptor ABI doesn't have interceptors for longjmp and setjmp. This patch introduces them. We require the size of the jmp_buf on the platform to be at least as large as the jmp_buf in our implementation. To enforce this we compile hwasan_type_test.cpp that ensures a compile time failure if this is not true. Tested on both GCC and clang using an AArch64 virtual machine. Reviewers: eugenis, kcc, pcc, Sanatizers Reviewed By: eugenis, Sanatizers Tags: #sanatizers, #llvm Differential Revision: https://reviews.llvm.org/D69045 Patch By: Matthew Malcomson <matthew.malcomson@arm.com>
* [hwasan] Fix typo in the error type.Evgenii Stepanov2019-10-281-1/+1
| | | | "alocation-tail-overwritten" -> "allocation-tail-overwritten"
* Add missing lld checks in sanitizer tests.Evgenii Stepanov2019-10-283-3/+3
| | | | | | Do not add an lld dependency when this target does not exist. In this case the system installation of lld is used (or whatever is detected with -fuse-ld=lld by default).
* Fix lld detection in standalone compiler-rt.Evgenii Stepanov2019-10-243-3/+9
| | | | | | | | | | | | | | | 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 Subscribers: dberris, mgorny, #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D69405
* [builtins][test] Avoid unportable mmap call in clear_cache_test.cRainer 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 llvm-svn: 375490
* [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. llvm-svn: 375471
* [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. llvm-svn: 375317
* [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] llvm-svn: 375315
* [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 llvm-svn: 375301
* [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 llvm-svn: 375296
* [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. llvm-svn: 375162
* [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
* 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
* 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-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 llvm-svn: 374384
* [Sanitizers] Fix getrandom testDavid Carlier2019-10-101-1/+1
| | | | llvm-svn: 374333
* [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 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-101-50/+0
| | | | | | | | | | 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-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 llvm-svn: 374293
* [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 llvm-svn: 374265
* [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
* [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
* [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-082-0/+63
| | | | | | | | | | | | Reviewers: vitalybuka Subscribers: srhines, #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D68431 llvm-svn: 373993
* [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 llvm-svn: 373979
OpenPOWER on IntegriCloud