summaryrefslogtreecommitdiffstats
path: root/compiler-rt/lib
Commit message (Collapse)AuthorAgeFilesLines
...
* Fix warning: format specifies type 'unsigned long' but the argument has type ↵Alexandre Ganea2019-11-041-0/+4
| | | | 'unsigned long long' [-Wformat]
* [hwasan] Remove lazy thread-initialisationDavid Spickett2019-11-042-16/+19
| | | | | | | | | | | | | | | | | | | | | This was an experiment made possible by a non-standard feature of the Android dynamic loader. It required introducing a flag to tell the compiler which ABI was being targeted. This flag is no longer needed, since the generated code now works for both ABI's. We leave that flag untouched for backwards compatibility. This also means that if we need to distinguish between targeted ABI's again we can do that without disturbing any existing workflows. We leave a comment in the source code and mention in the help text to explain this for any confused person reading the code in the future. Patch by Matthew Malcomson Differential Revision: https://reviews.llvm.org/D69574
* [compiler-rt] [msan] Correct the __libc_thr_keycreate prototypeKamil Rytarowski2019-11-041-2/+3
| | | | Fixes build with GCC8.
* [compiler-rt] Harmonize __sanitizer_addrinfo with the NetBSD headersKamil Rytarowski2019-11-031-0/+6
| | | | Add missing pad for sparc, alpha and a variation of i386.
* [compiler-rt] Sync NetBSD syscall hooks with 9.99.17Kamil Rytarowski2019-11-031-10/+46
| | | | | Document the minimal version supported as 9.0 and add compat code for renamed syscalls after 9.0.
* Disable exceptions in libfuzzer's copy of libcxxabi.Evgenii Stepanov2019-11-011-0/+1
| | | | | External project configuration for libcxxabi now has exceptions on by default, but this is not needed for libfuzzer.
* [compiler-rt] [profile] Fix building for MinGW after d889d1efefe9fMartin Storsjö2019-11-011-0/+1
| | | | | | | | This commit added use of a Windows API in InstrProfilingPort.h. When _MSC_VER is defined (for MSVC), windows.h is already included earlier in the same header (for atomics), but MinGW, the gcc atomics builtins are used instead. Therefore explicitly include windows.h here, where the API is used.
* [profile] Fifth speculative fix for Android after D68351Vedant Kumar2019-10-311-4/+4
| | | | | | | | | | | | | | | | | | | | | | Use the printf macros from inttypes.h to sidestep -Wformat issues: /var/lib/buildbot/sanitizer-buildbot6/sanitizer-x86_64-linux-android/build/llvm-project/compiler-rt/lib/profile/InstrProfilingFile.c:425:14: error: format specifies type 'long long' but the argument has type 'off_t' (aka 'long') [-Werror,-Wformat] CurrentFileOffset, PageSize); ^~~~~~~~~~~~~~~~~ /var/lib/buildbot/sanitizer-buildbot6/sanitizer-x86_64-linux-android/build/llvm-project/compiler-rt/lib/profile/InstrProfilingPort.h:114:50: note: expanded from macro 'PROF_ERR' fprintf(stderr, "LLVM Profile Error: " Format, __VA_ARGS__); ~~~~~~ ^~~~~~~~~~~ /var/lib/buildbot/sanitizer-buildbot6/sanitizer-x86_64-linux-android/build/llvm-project/compiler-rt/lib/profile/InstrProfilingFile.c:461:41: error: format specifies type 'unsigned long long' but the argument has type 'uint64_t' (aka 'unsigned long') [-Werror,-Wformat] strerror(errno), CountersBegin, PageAlignedCountersLength, Fileno, ^~~~~~~~~~~~~~~~~~~~~~~~~ /var/lib/buildbot/sanitizer-buildbot6/sanitizer-x86_64-linux-android/build/llvm-project/compiler-rt/lib/profile/InstrProfilingPort.h:114:50: note: expanded from macro 'PROF_ERR' fprintf(stderr, "LLVM Profile Error: " Format, __VA_ARGS__); ~~~~~~ ^~~~~~~~~~~ /var/lib/buildbot/sanitizer-buildbot6/sanitizer-x86_64-linux-android/build/llvm-project/compiler-rt/lib/profile/InstrProfilingFile.c:462:9: error: format specifies type 'unsigned long long' but the argument has type 'uint64_t' (aka 'unsigned long') [-Werror,-Wformat] FileOffsetToCounters); ^~~~~~~~~~~~~~~~~~~~ /var/lib/buildbot/sanitizer-buildbot6/sanitizer-x86_64-linux-android/build/llvm-project/compiler-rt/lib/profile/InstrProfilingPort.h:114:50: note: expanded from macro 'PROF_ERR' fprintf(stderr, "LLVM Profile Error: " Format, __VA_ARGS__);
* [profile] Third speculative fix for Windows after D68351Vedant Kumar2019-10-312-4/+8
| | | | | | | _putenv on Windows takes 1 argument, whereas setenv elsewhere takes 3. Just treat the two platforms differently. http://lab.llvm.org:8011/builders/sanitizer-windows/builds/53547
* [profile] Second speculative fix for WindowsVedant Kumar2019-10-311-1/+1
| | | | | | | | VLAs in C appear to not work on Windows, so use COMPILER_RT_ALLOCA: C:\b\slave\sanitizer-windows\llvm-project\compiler-rt\lib\profile\InstrProfilingWriter.c(264): error C2057: expected constant expression C:\b\slave\sanitizer-windows\llvm-project\compiler-rt\lib\profile\InstrProfilingWriter.c(264): error C2466: cannot allocate an array of constant size 0 C:\b\slave\sanitizer-windows\llvm-project\compiler-rt\lib\profile\InstrProfilingWriter.c(264): error C2133: 'Zeroes': unknown size
* [profile] Speculative fix for Windows after D68351Vedant Kumar2019-10-311-0/+1
| | | | | | setenv() appears to not be available on Windows: http://lab.llvm.org:8011/builders/sanitizer-windows/builds/53545/steps/stage%201%20build/logs/stdio
* [profile] Add a mode to continuously sync counter updates to a fileVedant Kumar2019-10-317-11/+287
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [scudo][standalone] Fix Secondary bug w/ freelistKostya Kortchinsky2019-10-313-6/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: cferris@ found an issue due to the new Secondary free list behavior and unfortunately it's completely my fault. The issue is twofold: - I lost track of the (major) fact that the Combined assumes that all chunks returned by the Secondary are zero'd out apprioriately when dealing with `ZeroContents`. With the introduction of the freelist, it's no longer the case as there can be a small portion of memory between the header and the next page boundary that is left untouched (the rest is zero'd via release). So the next time that block is returned, it's not fully zero'd out. - There was no test that would exercise that behavior :( There are several ways to fix this, the one I chose makes the most sense to me: we pass `ZeroContents` to the Secondary's `allocate` and it zero's out the block if requested and it's coming from the freelist. The prevents an extraneous `memset` in case the block comes from `map`. Another possbility could have been to `memset` in `deallocate`, but it's probably overzealous as all secondary blocks don't need to be zero'd out. Add a test that would have found the issue prior to fix. Reviewers: morehouse, hctim, cferris, pcc, eugenis, vitalybuka Subscribers: #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D69675
* [asan] Fix lint failure in asan_interface.hEvgenii Stepanov2019-10-311-1/+2
|
* [asan] Provide an interface to update an allocation stack trace.Evgenii Stepanov2019-10-313-0/+18
| | | | | | | | | | | | | | 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
* Sort HWASAN_RTL_SOURCES alphabetically (NFC).Evgenii Stepanov2019-10-311-1/+1
|
* [msan] Blacklist __gxx_personality_v0.Evgenii Stepanov2019-10-314-4/+39
| | | | | | | | | | | | | | | | | | | | Summary: Fixes https://bugs.llvm.org/show_bug.cgi?id=31877. Fixes https://github.com/google/sanitizers/issues/1155. Enables exceptions in msan/tsan buid of libcxx, and in msan tests. -fdepfile-entry stuff is a workaround for https://reviews.llvm.org/D69290 (default blacklist missing from -MMD output). Reviewers: pcc, dvyukov Subscribers: mgorny, christof, #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D69587
* [Builtins] Fix bug where powerpc builtins specializations didn't remove ↵Dan Liew2019-10-301-11/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | generic implementations. Summary: Previously the CMake code looked for filepaths of the form `<arch>/<filename>` as an indication that `<arch>/<filename>` provided a specialization of a top-level file `<filename>`. For powerpc there was a bug because the powerpc specialized implementations lived in `ppc/` but the architectures were `powerpc64` and `powerpc64le` which meant that CMake was looking for files at `powerpc64/<filename>` and `powerpc64le/<filename>`. The result of this is that for powerpc the builtins library contained a duplicate symbol for `divtc3` because it had the generic implementation and the specialized version in the built static library. Although we could just add similar code to what there is for arm (i.e. compute `${_arch}`) to fix this, this is extremely error prone (until r375150 no error was raised). Instead this patch takes a different approach that removes looking for the architecture name entirely. Instead this patch uses the convention that a source file in a sub-directory might be a specialization of a generic implementation and if a source file of the same name (ignoring extension) exists at the top-level then it is the corresponding generic implementation. This approach is much simpler because it doesn't require keeping track of different architecture names. This convention already existed in repository but previously it was implicit. This change makes it explicit. This patch is motivated by wanting to revert r375162 which worked around the powerpc bug found when r375150 landed. Once it lands we should revert r375162. Reviewers: phosek, beanz, compnerd, shiva0217, amyk, rupprecht, kongyi, mstorsjo, t.p.northover, weimingz, jroelofs, joerg, sidneym Subscribers: nemanjai, mgorny, kristof.beyls, jsji, shchenz, steven.zhang, #sanitizers, llvm-commits Tags: #llvm, #sanitizers Differential Revision: https://reviews.llvm.org/D69189
* [sanitizer_common] Create max_allocation_size_mb flag.Matt Morehouse2019-10-305-11/+44
| | | | | | | | | | | | | | | | | 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
* [scudo][standalone] Add a free list to the SecondaryKostya Kortchinsky2019-10-307-127/+178
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The secondary allocator is slow, because we map and unmap each block on allocation and deallocation. While I really like the security benefits of such a behavior, this yields very disappointing performance numbers on Android for larger allocation benchmarks. So this change adds a free list to the secondary, that will hold recently deallocated chunks, and (currently) release the extraneous memory. This allows to save on some memory mapping operations on allocation and deallocation. I do not think that this lowers the security of the secondary, but can increase the memory footprint a little bit (RSS & VA). The maximum number of blocks the free list can hold is templatable, `0U` meaning that we fallback to the old behavior. The higher that number, the higher the extra memory footprint. I added default configurations for all our platforms, but they are likely to change in the near future based on needs and feedback. Reviewers: hctim, morehouse, cferris, pcc, eugenis, vitalybuka Subscribers: mgorny, #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D69570
* [compiler-rt] libhwasan interceptor ABI intercept longjmp/setjmpDavid Tellenbach2019-10-305-0/+221
| | | | | | | | | | | | | | | | | | | | | | 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>
* [libc++] Force the ABI namespace to be a reserved identifierLouis Dionne2019-10-291-1/+1
| | | | | | | | | | | | | | | | Summary: When the ABI namespace isn't a reserved identifier, we were issuing a warning, but this should have been an error since the beginning. This commit enforces that the ABI namespace is a reserved identifier, and changes the ABI namespace used by LibFuzzer. Reviewers: phosek, EricWF Subscribers: mgorny, christof, jkorous, dexonsmith, #sanitizers, libcxx-commits, llvm-commits Tags: #sanitizers, #libc, #llvm Differential Revision: https://reviews.llvm.org/D69408
* [scudo][standalone] Lists fixKostya Kortchinsky2019-10-282-0/+15
| | | | | | | | | | | | | | | | | | | | | | Summary: Apparently during the review of D69265, and my flailing around with git, a somewhat important line disappeared. On top of that, there was no test exercising that code path, and while writing the follow up patch I intended to write, some `CHECK`s were failing. Re-add the missing line, and add a test that fails without said line. Reviewers: hctim, morehouse, pcc, cferris Reviewed By: hctim Subscribers: #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D69529
* [hwasan] Fix typo in the error type.Evgenii Stepanov2019-10-281-1/+1
| | | | "alocation-tail-overwritten" -> "allocation-tail-overwritten"
* [scudo][standalone] Consolidate listsKostya Kortchinsky2019-10-2810-186/+243
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is a clean patch using the last diff of D69265, but using git instead of svn, since svn went ro and arc was making my life harded than it needed to be. I was going to introduce a couple more lists and realized that our lists are currently a bit all over the place. While we have a singly linked list type relatively well defined, we are using doubly linked lists defined on the fly for the stats and for the secondary blocks. This CL adds a doubly linked list object, reorganizing the singly list one to extract as much of the common code as possible. We use this new type in the stats and the secondary. We also reorganize the list tests to benefit from this consolidation. There are a few side effect changes such as using for iterator loops that are, in my opinion, cleaner in a couple of places. Reviewers: hctim, morehouse, pcc, cferris Reviewed By: hctim Subscribers: jfb, #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D69516
* [AArch64][Builtins] Avoid unnecessary cache cleaningBryan Chan2019-10-281-13/+23
| | | | | | | | | | | | Use new control bits CTR_EL0.DIC and CTR_EL0.IDC to discover the d-cache cleaning and i-cache invalidation requirements for instruction-to-data coherence. This matches the behavior in the latest libgcc. Author: Shaokun Zhang <zhangshaokun@hisilicon.com> Reviewed By: peter.smith Differential Revision: https://reviews.llvm.org/D69247
* [libFuzzer] Enable extra counters for Fuchsia.Matt Morehouse2019-10-251-1/+1
|
* [compiler-rt] Expose __hwasan_tag_mismatch_stubDavid Tellenbach2019-10-243-17/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: GCC would like to emit a function call to report a tag mismatch rather than hard-code the `brk` instruction directly. __hwasan_tag_mismatch_stub contains most of the functionality to do this already, but requires exposure in the dynamic library. This patch moves __hwasan_tag_mismatch_stub outside of the anonymous namespace that it was defined in and declares it in hwasan_interface_internal.h. We also add the ability to pass sizes larger than 16 bytes to this reporting function by providing a fourth parameter that is only looked at when the size provided is not in the original accepted range. This does not change the behaviour where it is already being called, since the previous definition only accepted sizes up to 16 bytes and hence the change in behaviour is not seen by existing users. The change in declaration does not matter, since the only existing use is in the __hwasan_tag_mismatch function written in assembly. Reviewers: eugenis, kcc, pcc, #sanitizers Reviewed By: eugenis, #sanitizers Subscribers: kristof.beyls, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D69113 Patch by Matthew Malcomson <matthew.malcomson@arm.com>
* Revert "Expose __hwasan_tag_mismatch_stub"David Tellenbach2019-10-243-26/+17
| | | | | | Attribution to author of patch got lost. This reverts commit 612eadb7bc06b8f1a094976e06155f46ebd70d7c.
* Expose __hwasan_tag_mismatch_stubDavid Tellenbach2019-10-243-17/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: GCC would like to emit a function call to report a tag mismatch rather than hard-code the `brk` instruction directly. __hwasan_tag_mismatch_stub contains most of the functionality to do this already, but requires exposure in the dynamic library. This patch moves __hwasan_tag_mismatch_stub outside of the anonymous namespace that it was defined in and declares it in hwasan_interface_internal.h. We also add the ability to pass sizes larger than 16 bytes to this reporting function by providing a fourth parameter that is only looked at when the size provided is not in the original accepted range. This does not change the behaviour where it is already being called, since the previous definition only accepted sizes up to 16 bytes and hence the change in behaviour is not seen by existing users. The change in declaration does not matter, since the only existing use is in the __hwasan_tag_mismatch function written in assembly. Tested with gcc and clang on an AArch64 vm. Reviewers: eugenis, kcc, pcc, #sanitizers Reviewed By: eugenis, #sanitizers Subscribers: kristof.beyls, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D69113
* [Sanitizers] Add support for RISC-V 64-bitSam Elliott2019-10-235-7/+18
| | | | | | | | | | | | | | | | | 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
* [profile] Do not cache __llvm_profile_get_filename resultVedant Kumar2019-10-182-10/+16
| | | | | | | | | | | | | | | | | 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: Add missing SANITIZER_INTERFACE_ATTRIBUTE on ↵Peter Collingbourne2019-10-181-4/+7
| | | | | | | | __hwasan_personality_wrapper. Differential Revision: https://reviews.llvm.org/D69201 llvm-svn: 375298
* [hwasan] Remove system allocator fallback.Evgeniy Stepanov2019-10-183-37/+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
* Update global_symbols.txt.Peter Collingbourne2019-10-181-0/+1
| | | | llvm-svn: 375284
* 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 llvm-svn: 375276
* [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 llvm-svn: 375220
* 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 llvm-svn: 375166
* Revert [Sanitizers] Add support for RISC-V 64-bitSam Elliott2019-10-175-18/+7
| | | | | | This reverts r375132 (git commit 00bbe990c5d4472d5413479a539b3d6edbb3ca7a) llvm-svn: 375136
* [Sanitizers] Add support for RISC-V 64-bitSam Elliott2019-10-175-7/+18
| | | | | | | | | | | | | | | | | | | 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
* 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
* 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
* Reland "[ASan] Do not misrepresent high value address dereferences as null ↵Julian Lettner2019-10-106-6/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* 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-102-1/+18
| | | | | | | | | | | | | - 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
OpenPOWER on IntegriCloud