summaryrefslogtreecommitdiffstats
path: root/compiler-rt/lib/sanitizer_common/sanitizer_common.h
Commit message (Collapse)AuthorAgeFilesLines
...
* Mmap interceptor new option, Write Exec runtime detectorVitaly Buka2018-03-161-0/+2
| | | | | | | | | | | | | | | | Summary: Following-up the refactoring of mmap interceptors, adding a new common option to detect PROT_WRITE|PROT_EXEC pages request. Patch by David CARLIER Reviewers: vitalybuka, vsk Reviewed By: vitalybuka Subscribers: krytarowski, #sanitizers Differential Revision: https://reviews.llvm.org/D44194 llvm-svn: 327747
* Revert "Mmap interceptor new option, Write Exec runtime detector"Jonas Devlieghere2018-03-161-2/+0
| | | | | | | | | This reverts r327696 because it is failing on GreenDragon. http://green.lab.llvm.org/green/job/clang-stage1-configure-RA/43605/ http://green.lab.llvm.org/green/job/clang-stage1-cmake-RA-expensive/10957/ llvm-svn: 327719
* Mmap interceptor new option, Write Exec runtime detectorVitaly Buka2018-03-161-0/+2
| | | | | | | | | | | | | | | | Summary: Following-up the refactoring of mmap interceptors, adding a new common option to detect PROT_WRITE|PROT_EXEC pages request. Patch by David CARLIER Reviewers: vitalybuka, vsk Reviewed By: vitalybuka Subscribers: krytarowski, #sanitizers Differential Revision: https://reviews.llvm.org/D44194 llvm-svn: 327696
* [sanitizer] Align & pad the allocator structures to the cacheline size v2Kostya Kortchinsky2018-03-121-5/+1
| | | | | | | | | | | | | | | | | | | | Summary: This is a new version of D44261, which broke some builds with older gcc, as they can't align on a constexpr, but rather require an integer (see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56859) among others. We introduce `SANITIZER_CACHE_LINE_SIZE` in `sanitizer_platform.h` to be used in `ALIGNED` attributes instead of using directly `kCacheLineSize`. Reviewers: alekseyshl, thakis Reviewed By: alekseyshl Subscribers: kubamracek, delcypher, #sanitizers, llvm-commits Differential Revision: https://reviews.llvm.org/D44326 llvm-svn: 327297
* [sanitizer] Revert rCRT327145Kostya Kortchinsky2018-03-091-4/+2
| | | | | | | | | | | | | | | | | | | Summary: It breaks the Chromium toolchain due to: ``` lib/sanitizer_common/sanitizer_allocator_primary32.h:269:34: error: requested alignment is not an integer constant struct ALIGNED(kCacheLineSize) SizeClassInfo { ``` Reviewers: alekseyshl, thakis Reviewed By: thakis Subscribers: kubamracek, delcypher, #sanitizers, llvm-commits Differential Revision: https://reviews.llvm.org/D44320 llvm-svn: 327167
* [sanitizer] Align & pad the allocator structures to the cacheline sizeKostya Kortchinsky2018-03-091-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Both `SizeClassInfo` structures for the 32-bit primary & `RegionInfo` structures for the 64-bit primary can be used by different threads, and as such they should be aligned & padded to the cacheline size to avoid false sharing. The former was padded but the array was not aligned, the latter was not padded but we lucked up as the size of the structure was 192 bytes, and aligned by the properties of `mmap`. I plan on adding a couple of fields to the `RegionInfo`, and some highly threaded tests pointed out that without proper padding & alignment, performance was getting a hit - and it is going away with proper padding. This patch makes sure that we are properly padded & aligned for both. I used a template to avoid padding if the size is already a multiple of the cacheline size. There might be a better way to do this, I am open to suggestions. Reviewers: alekseyshl, dvyukov Reviewed By: alekseyshl Subscribers: kubamracek, delcypher, #sanitizers, llvm-commits Differential Revision: https://reviews.llvm.org/D44261 llvm-svn: 327145
* [asan] Be more careful and verbose when allocating dynamic shadow memoryKuba Mracek2018-02-261-1/+1
| | | | | | | | FindAvailableMemoryRange can currently overwrite existing memory (by restricting the VM below addresses that are already used). This patch adds a check to make sure we don't restrict the VM space too much. We are also now more explicit about why the lookup failed and print out verbose values. Differential Revision: https://reviews.llvm.org/D43318 llvm-svn: 326106
* [sanitizer] Introduce a vDSO aware timing functionKostya Kortchinsky2017-12-131-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: See D40657 & D40679 for previous versions of this patch & description. A couple of things were fixed here to have it not break some bots. Weak symbols can't be used with `SANITIZER_GO` so the previous version was breakin TsanGo. I set up some additional local tests and those pass now. I changed the workaround for the glibc vDSO issue: `__progname` is initialized after the vDSO and is actually public and of known type, unlike `__vdso_clock_gettime`. This works better, and with all compilers. The rest is the same. Reviewers: alekseyshl Reviewed By: alekseyshl Subscribers: srhines, kubamracek, krytarowski, llvm-commits, #sanitizers Differential Revision: https://reviews.llvm.org/D41121 llvm-svn: 320594
* [sanitizer] Revert rL320409Kostya Kortchinsky2017-12-111-1/+0
| | | | | | | | | | | | | | Summary: D40679 broke a couple of builds, reverting while investigating. Reviewers: alekseyshl Reviewed By: alekseyshl Subscribers: srhines, kubamracek, krytarowski, llvm-commits, #sanitizers Differential Revision: https://reviews.llvm.org/D41088 llvm-svn: 320417
* [sanitizer] Introduce a vDSO aware time function, and use it in the ↵Kostya Kortchinsky2017-12-111-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | allocator [redo] Summary: Redo of D40657, which had the initial discussion. The initial code had to move into a libcdep file, and things had to be shuffled accordingly. `NanoTime` is a time sink when checking whether or not to release memory to the OS. While reducing the amount of calls to said function is in the works, another solution that was found to be beneficial was to use a timing function that can leverage the vDSO. We hit a couple of snags along the way, like the fact that the glibc crashes when clock_gettime is called from a preinit_array, or the fact that `__vdso_clock_gettime` is mangled (for security purposes) and can't be used directly, and also that clock_gettime can be intercepted. The proposed solution takes care of all this as far as I can tell, and significantly improve performances and some Scudo load tests with memory reclaiming enabled. @mcgrathr: please feel free to follow up on https://reviews.llvm.org/D40657#940857 here. I posted a reply at https://reviews.llvm.org/D40657#940974. Reviewers: alekseyshl, krytarowski, flowerhack, mcgrathr, kubamracek Reviewed By: alekseyshl, krytarowski Subscribers: #sanitizers, mcgrathr, srhines, llvm-commits, kubamracek Differential Revision: https://reviews.llvm.org/D40679 llvm-svn: 320409
* [fuchsia] Update Fuchsia with a new mmap implementation.Kostya Kortchinsky2017-11-271-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Now that the sanitizer_common interface for MmapNoAccess / MmapFixed have been refactored to allow a more OO-esque access pattern, update the Fuchsia mmap implementation to take advantage of this. Previously MmapNoAccess / MmapFixed relied on a global allocator_vmar, since the sanitizer_allocator only called MmapNoAccess once. Now, we create a new VMAR per ReservedAddressRange object. This allows the sanitizer allocator to work in tandem with the Scudo secondary allocator. This is part 4 of a 4 part changeset: * part 1 https://reviews.llvm.org/D38593 * part 2 https://reviews.llvm.org/D38592 * part 3 https://reviews.llvm.org/D38593 Reviewers: mcgrathr, cryptoad Reviewed By: cryptoad Subscribers: alekseyshl, mcgrathr, kubamracek, mehdi_amini Differential Revision: https://reviews.llvm.org/D38595 llvm-svn: 319083
* [scudo] Make getNumberOfCPUs Fuchsia compliant v2Kostya Kortchinsky2017-11-211-0/+9
| | | | | | | | | | | | | | | | | | | Summary: This change allows Fuchsia to boot properly using the Scudo allocator. A first version of this commit was reverted by rL317834 because it broke Android builds for toolchains generated with older NDKs. This commit introduces a fall back to solve that issue. Reviewers: cryptoad, krytarowski, rnk, alekseyshl Reviewed By: cryptoad, krytarowski, alekseyshl Subscribers: llvm-commits, srhines, kubamracek, krytarowski Differential Revision: https://reviews.llvm.org/D40121 llvm-svn: 318802
* [sanitizers] Add init function to set alignment of low level allocatorWalter Lee2017-11-211-0/+2
| | | | | | | | | ASan requires that the min alignment be at least the shadow granularity, so add an init function to do that. Differential Revision: https://reviews.llvm.org/D39473 llvm-svn: 318717
* [asan] Use dynamic shadow on 32-bit Android, try 2.Evgeniy Stepanov2017-11-201-0/+1
| | | | | | | | | | | | | | | | Summary: This change reverts r318575 and changes FindDynamicShadowStart() to keep the memory range it found mapped PROT_NONE to make sure it is not reused. We also skip MemoryRangeIsAvailable() check, because it is (a) unnecessary, and (b) would fail anyway. Reviewers: pcc, vitalybuka, kcc Subscribers: srhines, kubamracek, mgorny, llvm-commits, hiraditya Differential Revision: https://reviews.llvm.org/D40203 llvm-svn: 318666
* Revert "[asan] Use dynamic shadow on 32-bit Android" and 3 more.Evgeniy Stepanov2017-11-181-1/+0
| | | | | | | | | | | | | | Revert the following commits: r318369 [asan] Fallback to non-ifunc dynamic shadow on android<22. r318235 [asan] Prevent rematerialization of &__asan_shadow. r317948 [sanitizer] Remove unnecessary attribute hidden. r317943 [asan] Use dynamic shadow on 32-bit Android. MemoryRangeIsAvailable() reads /proc/$PID/maps into an mmap-ed buffer that may overlap with the address range that we plan to use for the dynamic shadow mapping. This is causing random startup crashes. llvm-svn: 318575
* [asan] Use dynamic shadow on 32-bit Android.Evgeniy Stepanov2017-11-101-0/+1
| | | | | | | | | | | | | | | | | | | Summary: The following kernel change has moved ET_DYN base to 0x4000000 on arm32: https://marc.info/?l=linux-kernel&m=149825162606848&w=2 Switch to dynamic shadow base to avoid such conflicts in the future. Reserve shadow memory in an ifunc resolver, but don't use it in the instrumentation until PR35221 is fixed. This will eventually let use save one load per function. Reviewers: kcc Subscribers: aemerson, srhines, kubamracek, kristof.beyls, hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D39393 llvm-svn: 317943
* [sanitizer] Remove references and hide CommonSanitizerReportMutexVitaly Buka2017-11-101-4/+0
| | | | llvm-svn: 317865
* [sanitizer] Revert rL317822Kostya Kortchinsky2017-11-091-3/+0
| | | | | | | | | | | | | | | | | | | Summary: This reverts D39490. For toolchains generated with older NDKs (<=r13b as far as we tested), `cpu_set_t` doesn't exist in `sched.h`. We have to figure out another way to get the number of CPUs without this. Reviewers: rnk Reviewed By: rnk Subscribers: kubamracek, llvm-commits, krytarowski Differential Revision: https://reviews.llvm.org/D39867 llvm-svn: 317834
* [scudo] Make getNumberOfCPUs Fuchsia compliantKostya Kortchinsky2017-11-091-0/+3
| | | | | | | | | | | | | | Summary: This change allows Fuchsia to boot properly using the Scudo allocator. Reviewers: cryptoad, alekseyshl, krytarowski Reviewed By: cryptoad, krytarowski Subscribers: rnk, krytarowski, kubamracek, llvm-commits Differential Revision: https://reviews.llvm.org/D39490 llvm-svn: 317822
* Revert "[scudo] Make getNumberOfCPUs Fuchsia compliant"Reid Kleckner2017-11-081-3/+0
| | | | | | | | This reverts commit r317604. Android doesn't have cpu_set_t. llvm-svn: 317655
* (NFC) Rename GetMax{,User}VirtualAddress.Evgeniy Stepanov2017-11-071-1/+1
| | | | | | | Future change will introduce GetMaxVirtualAddress that will not take the kernel area into account. llvm-svn: 317638
* [scudo] Make getNumberOfCPUs Fuchsia compliantKostya Kortchinsky2017-11-071-0/+3
| | | | | | | | | | | | | | Summary: This change allows Fuchsia to boot properly using the Scudo allocator. Reviewers: cryptoad, alekseyshl, krytarowski Reviewed By: cryptoad, krytarowski Subscribers: krytarowski, kubamracek, llvm-commits Differential Revision: https://reviews.llvm.org/D39490 llvm-svn: 317604
* Update sanitizer_allocator to use new API.Kostya Kortchinsky2017-11-071-1/+2
| | | | | | | | | | | | | | | | | | | | | Summary: Update sanitizer_allocator to use new API. Second patch in a series. First patch https://reviews.llvm.org/D39072 Updates MmapNoAccess / MmapFixed call sites in the saniziter_allocator to use the new Init/Map APIs instead. Reviewers: alekseyshl, cryptoad, phosek, mcgrathr, dvyukov Reviewed By: alekseyshl, cryptoad Subscribers: dvyukov, mcgrathr, kubamracek Differential Revision: https://reviews.llvm.org/D38592 llvm-svn: 317586
* Introduce ReservedAddressRange to sanitizer_common.Kostya Kortchinsky2017-10-301-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Fixed version of https://reviews.llvm.org/D38437 (fixes Win/Fuchsia failures). Creating a new revision, since the old one was getting a bit old/crowded. In Fuchsia, MmapNoAccess/MmapFixedOrDie are implemented using a global VMAR, which means that MmapNoAccess can only be called once. This works for the sanitizer allocator but *not* for the Scudo allocator. Hence, this changeset introduces a new ReservedAddressRange object to serve as the new API for these calls. In this changeset, the object still calls into the old Mmap implementations. The next changeset two changesets will convert the sanitizer and scudo allocators to use the new APIs, respectively. (ReservedAddressRange will replace the SecondaryHeader in Scudo.) Finally, a last changeset will update the Fuchsia implementation. Reviewers: alekseyshl, cryptoad, phosek Reviewed By: alekseyshl, cryptoad Subscribers: kubamracek Differential Revision: https://reviews.llvm.org/D39072 llvm-svn: 316934
* Revert r315533 "Reland "[sanitizer] Introduce ReservedAddressRange to ↵Hans Wennborg2017-10-121-14/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | sanitizer_common"" The SanitizerCommon.ReservedAddressRangeUnmap test fails on Windows: FAIL: SanitizerCommon-Unit :: ./Sanitizer-x86_64-Test.exe/SanitizerCommon.ReservedAddressRangeUnmap (34003 of 35554) ******************** TEST 'SanitizerCommon-Unit :: ./Sanitizer-x86_64-Test.exe/SanitizerCommon.ReservedAddressRangeUnmap' FAILED ******************** Note: Google Test filter = SanitizerCommon.ReservedAddressRangeUnmap [==========] Running 1 test from 1 test case. [----------] Global test environment set-up. [----------] 1 test from SanitizerCommon [ RUN ] SanitizerCommon.ReservedAddressRangeUnmap ==3780==ERROR: SanitizerTool failed to deallocate 0x1000 (4096) bytes at address 0x0000000c3000 (error code: 487) ==3780==Sanitizer CHECK failed: E:\b\build\slave\win_upload_clang\build\src\third_party\llvm\projects\compiler-rt\lib\sanitizer_common\sanitizer_win.cc:129 (("unable to unmap" && 0)) != (0) (0, 0) ******************** Testing: 0 .. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90.. Testing Time: 299.76s ******************** Failing Tests (1): SanitizerCommon-Unit :: ./Sanitizer-x86_64-Test.exe/SanitizerCommon.ReservedAddressRangeUnmap > In Fuchsia, MmapNoAccess/MmapFixedOrDie are implemented using a global > VMAR, which means that MmapNoAccess can only be called once. This works > for the sanitizer allocator but *not* for the Scudo allocator. > > Hence, this changeset introduces a new ReservedAddressRange object to > serve as the new API for these calls. In this changeset, the object > still calls into the old Mmap implementations. > > The next changeset two changesets will convert the sanitizer and scudo > allocators to use the new APIs, respectively. (ReservedAddressRange will > replace the SecondaryHeader in Scudo.) > > Finally, a last changeset will update the Fuchsia implementation. > > Patch by Julia Hansbrough > > Differential Revision: https://reviews.llvm.org/D38437 llvm-svn: 315553
* Reland "[sanitizer] Introduce ReservedAddressRange to sanitizer_common"Petr Hosek2017-10-111-0/+14
| | | | | | | | | | | | | | | | | | | | | | In Fuchsia, MmapNoAccess/MmapFixedOrDie are implemented using a global VMAR, which means that MmapNoAccess can only be called once. This works for the sanitizer allocator but *not* for the Scudo allocator. Hence, this changeset introduces a new ReservedAddressRange object to serve as the new API for these calls. In this changeset, the object still calls into the old Mmap implementations. The next changeset two changesets will convert the sanitizer and scudo allocators to use the new APIs, respectively. (ReservedAddressRange will replace the SecondaryHeader in Scudo.) Finally, a last changeset will update the Fuchsia implementation. Patch by Julia Hansbrough Differential Revision: https://reviews.llvm.org/D38437 llvm-svn: 315533
* Revert "[sanitizer] Introduce ReservedAddressRange to sanitizer_common"Petr Hosek2017-10-111-14/+0
| | | | | | This reverts commit r315493 which is failing to build on sanitizer-windows. llvm-svn: 315494
* [sanitizer] Introduce ReservedAddressRange to sanitizer_commonPetr Hosek2017-10-111-0/+14
| | | | | | | | | | | | | | | | | | | | | | In Fuchsia, MmapNoAccess/MmapFixedOrDie are implemented using a global VMAR, which means that MmapNoAccess can only be called once. This works for the sanitizer allocator but *not* for the Scudo allocator. Hence, this changeset introduces a new ReservedAddressRange object to serve as the new API for these calls. In this changeset, the object still calls into the old Mmap implementations. The next changeset two changesets will convert the sanitizer and scudo allocators to use the new APIs, respectively. (ReservedAddressRange will replace the SecondaryHeader in Scudo.) Finally, a last changeset will update the Fuchsia implementation. Patch by Julia Hansbrough Differential Revision: https://reviews.llvm.org/D38759 llvm-svn: 315493
* Add support for custom loaders to the sanitizer symbolizerFrancis Ricci2017-10-021-0/+1
| | | | | | | | | | | | | | | | | Summary: Adds a fallback mode to procmaps when the symbolizer fails to locate a module for a given address by using dl_iterate_phdr. Reviewers: kubamracek, rnk, vitalybuka, eugenis Reviewed By: eugenis Subscribers: srhines, llvm-commits Differential Revision: https://reviews.llvm.org/D37269 llvm-svn: 314713
* Revert "Add support for custom loaders to the sanitizer symbolizer"Francis Ricci2017-10-021-1/+0
| | | | | | This reverts commit r314671, which hangs on the gcc sanitizer buildbot. llvm-svn: 314684
* Add support for custom loaders to the sanitizer symbolizerFrancis Ricci2017-10-021-0/+1
| | | | | | | | | | | | | | | | | Summary: Adds a fallback mode to procmaps when the symbolizer fails to locate a module for a given address by using dl_iterate_phdr. Reviewers: kubamracek, rnk, vitalybuka, eugenis Reviewed By: eugenis Subscribers: srhines, llvm-commits Differential Revision: https://reviews.llvm.org/D37269 llvm-svn: 314671
* Move LoadedModule list to a NoCtor vector and initialize on demand.Francis Ricci2017-09-291-2/+7
| | | | | | | Unreverting this patch because llvm-clang-lld-x86_64-debian-fast started passing again before the revert hit. Must've been just a flake. llvm-svn: 314556
* Revert "Move LoadedModule list to a NoCtor vector and initialize on demand."Francis Ricci2017-09-291-7/+2
| | | | | | | | | I think this may have introduced a failure on llvm-clang-lld-x86_64-debian-fast This reverts commit r314533 llvm-svn: 314552
* Move LoadedModule list to a NoCtor vector and initialize on demand.Francis Ricci2017-09-291-2/+7
| | | | llvm-svn: 314533
* Revert "Add support for custom loaders to the sanitizer symbolizer"Francis Ricci2017-09-281-8/+2
| | | | | | | | This causes the gcc sanitizer buildbot to timeout. This reverts commit 81f388fe570e5b6460dd5bc9b9a36b72714eeb68. llvm-svn: 314453
* Add support for custom loaders to the sanitizer symbolizerFrancis Ricci2017-09-281-2/+8
| | | | | | | | | | | | | | | | | Summary: Adds a fallback mode to procmaps when the symbolizer fails to locate a module for a given address by using dl_iterate_phdr. Reviewers: kubamracek, rnk, vitalybuka, eugenis Reviewed By: eugenis Subscribers: srhines, llvm-commits Differential Revision: https://reviews.llvm.org/D37269 llvm-svn: 314431
* Revert "Add support for custom loaders to symbolizer"Francis Ricci2017-09-271-6/+2
| | | | | | | | This broke the windows buildbots, revert for now. This reverts commit 24050b5ddef42f6f3306aa94d4a1f42a7893a9a7. llvm-svn: 314347
* Add support for custom loaders to symbolizerFrancis Ricci2017-09-271-2/+6
| | | | | Change-Id: I5594bd6b216deca2c73cf0a7001f9aec1e803c60 llvm-svn: 314342
* [sanitizer_common] Don't provide sanitizer_procmaps API functions where not ↵Francis Ricci2017-09-251-0/+8
| | | | | | | | | | | | | | | | | defined Summary: Platforms that don't implement procmaps (primarily fuchsia and windows) still expose the procmaps API when including sanitizer_procmaps.h, despite not implementing the functions provided by that header. Ensure that the API is only exposed on platforms that implement it. Reviewers: vitalybuka, alekseyshl, kubamracek Subscribers: llvm-commits, krytarowski Differential Revision: https://reviews.llvm.org/D38187 llvm-svn: 314149
* [ubsan] Replace CommonSanitizerReportMutex with ScopedErrorReportLockVitaly Buka2017-09-231-0/+2
| | | | | | | | | | Reviewers: eugenis, alekseyshl Subscribers: kubamracek, llvm-commits Differential Revision: https://reviews.llvm.org/D38194 llvm-svn: 314053
* [lsan] Deadly signal handler for lsanVitaly Buka2017-09-221-1/+10
| | | | | | | | | | | | Summary: Part of https://github.com/google/sanitizers/issues/637 Reviewers: eugenis, alekseyshl Subscribers: llvm-commits, dberris, kubamracek, krytarowski Differential Revision: https://reviews.llvm.org/D37608 llvm-svn: 314041
* [sanitizer] Replace thread id with GetThreadSelfVitaly Buka2017-09-221-1/+1
| | | | | | This allows to avoid constructor parameter llvm-svn: 314040
* [sanitizer] Move report locking code from asan into commonVitaly Buka2017-09-221-0/+8
| | | | llvm-svn: 314008
* [sanitizer] Move stack overflow and signal reporting from Asan into common.Vitaly Buka2017-09-141-4/+8
| | | | | | | | | | | | Summary: Part of https://github.com/google/sanitizers/issues/637 Reviewers: eugenis, alekseyshl Subscribers: kubamracek Differential Revision: https://reviews.llvm.org/D37844 llvm-svn: 313310
* [sanitizer] Move IsStackOverflow into SignalContextVitaly Buka2017-09-141-1/+3
| | | | llvm-svn: 313227
* [compiler-rt] Cleanup SignalContext initializationVitaly Buka2017-09-141-17/+15
| | | | | | | | | | Reviewers: eugenis, alekseyshl Subscribers: kubamracek, dberris Differential Revision: https://reviews.llvm.org/D37827 llvm-svn: 313223
* [compiler-rt] Use SignalContext in ErrorStackOverflow and ErrorDeadlySignalVitaly Buka2017-09-131-2/+4
| | | | | | | | | | | | Summary: Part of https://github.com/google/sanitizers/issues/637 Reviewers: eugenis, alekseyshl, filcab Subscribers: kubamracek, llvm-commits, dberris Differential Revision: https://reviews.llvm.org/D37793 llvm-svn: 313168
* [compiler-rt] Add siginfo into SignalContextVitaly Buka2017-09-131-4/+14
| | | | | | | | | | | | | | | Summary: Information stored there is often been passed along with SignalContext. Part of https://github.com/google/sanitizers/issues/637 Reviewers: eugenis, alekseyshl Subscribers: kubamracek, llvm-commits, dberris Differential Revision: https://reviews.llvm.org/D37792 llvm-svn: 313167
* [compiler-rt] Move dump_instruction_bytes and dump_registers into ↵Vitaly Buka2017-09-131-0/+4
| | | | | | | | | | | | | | sanitizer_common Summary: Part of https://github.com/google/sanitizers/issues/637 Reviewers: eugenis, alekseyshl Subscribers: kubamracek, llvm-commits, dberris Differential Revision: https://reviews.llvm.org/D37766 llvm-svn: 313117
* [compiler-rt] Move *Sanitizer:DEADLYSIGNAL printing into common partVitaly Buka2017-09-131-1/+3
| | | | | | | | | | | | Summary: Part of https://github.com/google/sanitizers/issues/637 Reviewers: eugenis, alekseyshl Subscribers: kubamracek, llvm-commits, dberris Differential Revision: https://reviews.llvm.org/D37764 llvm-svn: 313115
OpenPOWER on IntegriCloud