summaryrefslogtreecommitdiffstats
path: root/compiler-rt/lib/hwasan
Commit message (Collapse)AuthorAgeFilesLines
* [hwasan] Offline symbolization script.Evgenii Stepanov2019-12-093-0/+286
| | | | | | | | | | | | | | | Summary: A script to symbolize hwasan reports after the fact using unstripped binaries. Supports stack-based reports. Requires llvm-symbolizer (addr2line is not an option). Reviewers: pcc, hctim Subscribers: mgorny, #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D71148
* Make memory dump same as the one in asan.Martin Liska2019-11-271-1/+2
| | | | | | | Shadow memory (and short granules) are not prepended with memory address and arrow at the end of line is removed. Differential Revision: https://reviews.llvm.org/D70707
* [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
* Sort HWASAN_RTL_SOURCES alphabetically (NFC).Evgenii Stepanov2019-10-311-1/+1
|
* [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>
* [hwasan] Fix typo in the error type.Evgenii Stepanov2019-10-281-1/+1
| | | | "alocation-tail-overwritten" -> "allocation-tail-overwritten"
* [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
* 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
* 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
* hwasan: Compatibility fixes for short granules.Peter Collingbourne2019-09-271-2/+48
| | | | | | | | | | | | | | | | | | | | | | | | | We can't use short granules with stack instrumentation when targeting older API levels because the rest of the system won't understand the short granule tags stored in shadow memory. Moreover, we need to be able to let old binaries (which won't understand short granule tags) run on a new system that supports short granule tags. Such binaries will call the __hwasan_tag_mismatch function when their outlined checks fail. We can compensate for the binary's lack of support for short granules by implementing the short granule part of the check in the __hwasan_tag_mismatch function. Unfortunately we can't do anything about inline checks, but I don't believe that we can generate these by default on aarch64, nor did we do so when the ABI was fixed. A new function, __hwasan_tag_mismatch_v2, is introduced that lets code targeting the new runtime avoid redoing the short granule check. Because tag mismatches are rare this isn't important from a performance perspective; the main benefit is that it introduces a symbol dependency that prevents binaries targeting the new runtime from running on older (i.e. incompatible) runtimes. Differential Revision: https://reviews.llvm.org/D68059 llvm-svn: 373035
* [compiler-rt] Better lint output for .inc filesVitaly Buka2019-09-121-1/+1
| | | | llvm-svn: 371702
* Remove NOLINTs from compiler-rtVitaly Buka2019-09-111-1/+1
| | | | llvm-svn: 371687
* hwasan: Align n_namesz and n_descsz to 4 when reading notes.Peter Collingbourne2019-08-231-2/+2
| | | | | | | | | | There is no requirement for the producer of a note to include the note alignment in these fields. As a result we can end up missing the HWASAN note if one of the other notes in the binary has the alignment missing. Differential Revision: https://reviews.llvm.org/D66692 llvm-svn: 369826
* hwasan: Untag unwound stack frames by wrapping personality functions.Peter Collingbourne2019-08-232-0/+65
| | | | | | | | | | | | | | | | | | | | | | | One problem with untagging memory in landing pads is that it only works correctly if the function that catches the exception is instrumented. If the function is uninstrumented, we have no opportunity to untag the memory. To address this, replace landing pad instrumentation with personality function wrapping. Each function with an instrumented stack has its personality function replaced with a wrapper provided by the runtime. Functions that did not have a personality function to begin with also get wrappers if they may be unwound past. As the unwinder calls personality functions during stack unwinding, the original personality function is called and the function's stack frame is untagged by the wrapper if the personality function instructs the unwinder to keep unwinding. If unwinding stops at a landing pad, the function is still responsible for untagging its stack frame if it resumes unwinding. The old landing pad mechanism is preserved for compatibility with old runtimes. Differential Revision: https://reviews.llvm.org/D66377 llvm-svn: 369721
* hwasan: Add a code model check for tagged globals.Peter Collingbourne2019-08-081-4/+34
| | | | | | | | | | See D65364 for the code model requirements for tagged globals. Because of the relocations used these requirements cannot be checked at link time so they must be checked at runtime. Differential Revision: https://reviews.llvm.org/D65968 llvm-svn: 368351
* hwasan: Instrument globals.Peter Collingbourne2019-08-064-20/+138
| | | | | | | | | | | | | | | | | | Globals are instrumented by adding a pointer tag to their symbol values and emitting metadata into a special section that allows the runtime to tag their memory when the library is loaded. Due to order of initialization issues explained in more detail in the comments, shadow initialization cannot happen during regular global initialization. Instead, the location of the global section is marked using an ELF note, and we require libc support for calling a function provided by the HWASAN runtime when libraries are loaded and unloaded. Based on ideas discussed with @evgeny777 in D56672. Differential Revision: https://reviews.llvm.org/D65770 llvm-svn: 368102
* [Sanitizer] Linux refactor shadow huge page mode handlingDavid Carlier2019-08-051-2/+1
| | | | | | | | | | | | Disabling Transparent huge page mode refactored in one function. Reviewers: vitalybuka Reviewed By: vitalybuka Differential Revision: https://reviews.llvm.org/D65771 llvm-svn: 367925
* compiler-rt: Call a generated c++ file in hwasan .cpp instead of .ccNico Weber2019-08-011-3/+3
| | | | llvm-svn: 367572
* hwasan: Improve precision of checks using short granule tags.Peter Collingbourne2019-07-095-127/+135
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A short granule is a granule of size between 1 and `TG-1` bytes. The size of a short granule is stored at the location in shadow memory where the granule's tag is normally stored, while the granule's actual tag is stored in the last byte of the granule. This means that in order to verify that a pointer tag matches a memory tag, HWASAN must check for two possibilities: * the pointer tag is equal to the memory tag in shadow memory, or * the shadow memory tag is actually a short granule size, the value being loaded is in bounds of the granule and the pointer tag is equal to the last byte of the granule. Pointer tags between 1 to `TG-1` are possible and are as likely as any other tag. This means that these tags in memory have two interpretations: the full tag interpretation (where the pointer tag is between 1 and `TG-1` and the last byte of the granule is ordinary data) and the short tag interpretation (where the pointer tag is stored in the granule). When HWASAN detects an error near a memory tag between 1 and `TG-1`, it will show both the memory tag and the last byte of the granule. Currently, it is up to the user to disambiguate the two possibilities. Because this functionality obsoletes the right aligned heap feature of the HWASAN memory allocator (and because we can no longer easily test it), the feature is removed. Also update the documentation to cover both short granule tags and outlined checks. Differential Revision: https://reviews.llvm.org/D63908 llvm-svn: 365551
* hwasan: Fix an off-by-one error in PrintTagsAroundAddr.Peter Collingbourne2019-06-271-1/+1
| | | | | | | | Previously we were printing 16 rows of tags, not 17. Differential Revision: https://reviews.llvm.org/D63906 llvm-svn: 364609
* hwasan: Teach the runtime to identify the local variable being accessed in ↵Peter Collingbourne2019-06-273-60/+78
| | | | | | | | | | | | | | UAR reports. Each function's PC is recorded in the ring buffer. From there we can access the function's local variables and reconstruct the tag of each one with the help of the information printed by llvm-symbolizer's new FRAME command. We can then find the variable that was likely being accessed by matching the pointer's tag against the reconstructed tag. Differential Revision: https://reviews.llvm.org/D63469 llvm-svn: 364607
* hwasan: Use bits [3..11) of the ring buffer entry address as the base stack tag.Peter Collingbourne2019-06-171-0/+5
| | | | | | | | | | | | | | This saves roughly 32 bytes of instructions per function with stack objects and causes us to preserve enough information that we can recover the original tags of all stack variables. Now that stack tags are deterministic, we no longer need to pass -hwasan-generate-tags-with-calls during check-hwasan. This also means that the new stack tag generation mechanism is exercised by check-hwasan. Differential Revision: https://reviews.llvm.org/D63360 llvm-svn: 363636
* Improve error message when '=' is missing in {ASAN,...}_OPTIONS.Vitaly Buka2019-06-151-5/+2
| | | | | | | | | | | | | | | | | | Summary: It's handling isses as described here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89832 Patch by Martin Liška. Reviewers: kcc, vitalybuka Reviewed By: vitalybuka Subscribers: cryptoad, kubamracek Differential Revision: https://reviews.llvm.org/D59876 llvm-svn: 363480
* [HWASAN] Make new/delete weakEugene Leviant2019-06-041-8/+8
| | | | | | | | | This allows instrumenting programs which have their own versions of new and delete operators. Differential revision: https://reviews.llvm.org/D62794 llvm-svn: 362478
* [HWASAN] Remove unused codeEugene Leviant2019-05-292-28/+0
| | | | | | Differential revision: https://reviews.llvm.org/D62489 llvm-svn: 361942
* Fix some gcc warnings in compiler-rtNico Weber2019-05-101-2/+2
| | | | | | | | - Several "warning: extra ';' [-Wpedantic]" - One "C++ style comments are not allowed in ISO C90 [enabled by default]" in a file that uses C style comments everywhere but in one place llvm-svn: 360430
* [hwasan] Fix HWASAN_WITH_INTERCEPTORS=OFF build on not-android.Evgeniy Stepanov2019-05-031-1/+11
| | | | | | | | | | | | | | | | | Summary: I'm not aware of any platforms where this will work, but the code should at least compile. HWASAN_WITH_INTERCEPTORS=OFF means there is magic in libc that would call __hwasan_thread_enter / __hwasan_thread_exit as appropriate. Reviewers: pcc, winksaville Subscribers: srhines, kubamracek, #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D61337 llvm-svn: 359914
* [sanitizer][NFC] Set LargeMmapAllocator type from PrimaryAllocatorVitaly Buka2019-05-011-2/+1
| | | | | | | | | | | | | | They need to have same AddressSpaceView and MapUnmapCallback. Reviewers: eugenis Subscribers: kubamracek, #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D61168 llvm-svn: 359719
* [sanitizer][NFC] Get type of AllocatorCache from CombinedAllocatorVitaly Buka2019-05-011-3/+2
| | | | | | | | | | | | | | Reviewers: eugenis, cryptoad, kcc Reviewed By: kcc Subscribers: kcc, kubamracek, #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D61155 llvm-svn: 359715
* [sanitizer] Implement reallocarray.Evgeniy Stepanov2019-05-014-0/+20
| | | | | | | | | | | | | | | | Summary: It's a cross of calloc and realloc. Sanitizers implement calloc-like check for size overflow. Reviewers: vitalybuka, kcc Subscribers: kubamracek, #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D61108 llvm-svn: 359708
* [HWASan] Fixed slow DWARF unwinding.Mitch Phillips2019-04-161-3/+3
| | | | | | | | | | | | | | | | Summary: CFA was setup incorrectly, as there is an 8-byte gap at the top of the stack for SP 16-byte alignment purposes. Reviewers: eugenis Reviewed By: eugenis Subscribers: kubamracek, javed.absar, #sanitizers, llvm-commits, pcc Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D60798 llvm-svn: 358535
* [HWASan] Use less Printf() calls in register dump.Mitch Phillips2019-03-141-16/+22
| | | | | | | | | | | | | | | | | | | | Summary: Explicitly print 4 registers/line in each iteration during register dump. Reduces logcat spam as we get a single logcat message per call to Printf(), even if the output isn't newline-terminated. This brings the output format in logcat closer to that of the normal textual dump. Reviewers: eugenis, pcc Reviewed By: pcc Subscribers: kubamracek, #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D59320 llvm-svn: 356166
* [HWASan] Remove address significance from tag_mismatch.Mitch Phillips2019-03-111-6/+0
| | | | | | Actually fix the issue referenced in rL355840. llvm-svn: 355844
* [HWASan] Fixed minor AArch64/GCC build error.Mitch Phillips2019-03-111-0/+4
| | | | | | | Fixed buildbot clang-cmake-aarch64-lld by ensuring clang-only features are guarded by clang-only #defines. llvm-svn: 355840
* [HWASan] Save + print registers when tag mismatch occurs in AArch64.Mitch Phillips2019-03-086-8/+158
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This change change the instrumentation to allow users to view the registers at the point at which tag mismatch occured. Most of the heavy lifting is done in the runtime library, where we save the registers to the stack and emit unwind information. This allows us to reduce the overhead, as very little additional work needs to be done in each __hwasan_check instance. In this implementation, the fast path of __hwasan_check is unmodified. There are an additional 4 instructions (16B) emitted in the slow path in every __hwasan_check instance. This may increase binary size somewhat, but as most of the work is done in the runtime library, it's manageable. The failure trace now contains a list of registers at the point of which the failure occured, in a format similar to that of Android's tombstones. It currently has the following format: Registers where the failure occurred (pc 0x0055555561b4): x0 0000000000000014 x1 0000007ffffff6c0 x2 1100007ffffff6d0 x3 12000056ffffe025 x4 0000007fff800000 x5 0000000000000014 x6 0000007fff800000 x7 0000000000000001 x8 12000056ffffe020 x9 0200007700000000 x10 0200007700000000 x11 0000000000000000 x12 0000007fffffdde0 x13 0000000000000000 x14 02b65b01f7a97490 x15 0000000000000000 x16 0000007fb77376b8 x17 0000000000000012 x18 0000007fb7ed6000 x19 0000005555556078 x20 0000007ffffff768 x21 0000007ffffff778 x22 0000000000000001 x23 0000000000000000 x24 0000000000000000 x25 0000000000000000 x26 0000000000000000 x27 0000000000000000 x28 0000000000000000 x29 0000007ffffff6f0 x30 00000055555561b4 ... and prints after the dump of memory tags around the buggy address. Every register is saved exactly as it was at the point where the tag mismatch occurs, with the exception of x16/x17. These registers are used in the tag mismatch calculation as scratch registers during __hwasan_check, and cannot be saved without affecting the fast path. As these registers are designated as scratch registers for linking, there should be no important information in them that could aid in debugging. Reviewers: pcc, eugenis Reviewed By: pcc, eugenis Subscribers: srhines, kubamracek, mgorny, javed.absar, krytarowski, kristof.beyls, hiraditya, jdoerfert, llvm-commits, #sanitizers Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D58857 llvm-svn: 355738
* [NFC][Sanitizer] Make GetStackTrace a private method of BufferedStackTraceJulian Lettner2019-03-011-10/+8
| | | | | | | | | | GetStackTrace is a implementation detail of BufferedStackTrace. Make it a private method. Reviewed By: vitalybuka Differential-Revision: https://reviews.llvm.org/D58753 llvm-svn: 355232
* [NFC][Sanitizer] Add new BufferedStackTrace::Unwind APIJulian Lettner2019-03-012-11/+9
| | | | | | | | | | | | | | | | | | | | | Retrying without replacing call sites in sanitizer_common (which might not have a symbol definition). Add new Unwind API. This is the final envisioned API with the correct abstraction level. It hides/slow fast unwinder selection from the caller and doesn't take any arguments that would leak that abstraction (i.e., arguments like stack_top/stack_bottom). GetStackTrace will become an implementation detail (private method) of the BufferedStackTrace class. Reviewers: vitalybuka Differential Revision: https://reviews.llvm.org/D58741 > llvm-svn: 355168 llvm-svn: 355172
* Revert "[NFC][Sanitizer] Add new BufferedStackTrace::Unwind API"Julian Lettner2019-03-012-9/+11
| | | | | | This reverts commit 6112f37e758ebf2405955e091a745f5003c1f562. llvm-svn: 355171
* [NFC][Sanitizer] Add new BufferedStackTrace::Unwind APIJulian Lettner2019-03-012-11/+9
| | | | | | | | | | | | | | | | Add new Unwind API. This is the final envisioned API with the correct abstraction level. It hides/slow fast unwinder selection from the caller and doesn't take any arguments that would leak that abstraction (i.e., arguments like stack_top/stack_bottom). GetStackTrace will become an implementation detail (private method) of the BufferedStackTrace class. Reviewers: vitalybuka Differential Revision: https://reviews.llvm.org/D58741 llvm-svn: 355168
* [hwasan] Disable vfork code when building w/o interceptors.Evgeniy Stepanov2019-03-011-1/+1
| | | | | | Don't define vfork when OMPILER_RT_HWASAN_WITH_INTERCEPTORS=OFF. llvm-svn: 355165
* [hwasan] Fix vfork handling with large stack limit.Evgeniy Stepanov2019-02-281-3/+1
| | | | | | | | | | | Remove the maximum stack cleanup size check. With ulimit -s unlimited main thread stack can be very large, but we don't really have a choice other than cleaning all of it. It should be reasonably fast - hwasan cleans large shadow ranges with a single madvise call. This change fixes check-hwasan after ulimit -s unlimited. llvm-svn: 355137
* [NFC][Sanitizer] Pull up GetStackTrace into sanitizer_commonJulian Lettner2019-02-272-23/+22
| | | | | | | | | | | | | | | | | | | | We already independently declare GetStackTrace in all (except TSan) sanitizer runtime headers. Lets move it to sanitizer_stacktrace.h to have one canonical way to fill in a BufferedStackFrame. Also enables us to use it in sanitizer_common itself. This patch defines GetStackTrace for TSan and moves the function from ubsan_diag.cc to ubsan_diag_standalone.cc to avoid duplicate symbols for the UBSan-ASan runtime. Other than that this patch just moves the code out of headers and into the correct namespace. Reviewers: vitalybuka Differential Revision: https://reviews.llvm.org/D58651 llvm-svn: 355039
* [hwasan, asan] Intercept vfork.Evgeniy Stepanov2019-02-276-1/+50
| | | | | | | | | | | | | | | Summary: Intercept vfork on arm, aarch64, i386 and x86_64. Reviewers: pcc, vitalybuka Subscribers: kubamracek, mgorny, javed.absar, krytarowski, kristof.beyls, #sanitizers, llvm-commits Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D58533 llvm-svn: 355030
* [NFC][Sanitizer] Hard-code fast/slow unwinder at call siteJulian Lettner2019-02-271-2/+5
| | | | | | | | | | | | | Also assert that the caller always gets what it requested. This purely mechanical change simplifies future refactorings and eventual removal of BufferedStackTrace::Unwind. Reviewers: vitalybuka Differential Revision: https://reviews.llvm.org/D58557 llvm-svn: 355022
* hwasan: Rename source files from cc to cppNico Weber2019-02-2712-20/+21
| | | | | | | | | | | | | | | | | | | As discussed elsewhere: LLVM uses cpp as its C++ source extension; the sanitizers should too. This updates files in hwasan. Patch generated by for f in lib/hwasan/*.cc ; do svn mv $f ${f%.cc}.cpp; done followed by for f in lib/hwasan/*.cpp ; do sed -i '' -e '1s/\.cc -/.cpp /' $f; done CMakeLists.txt updated manually. Differential Revision: https://reviews.llvm.org/D58620 llvm-svn: 354989
* Revert "[asan] Fix vfork handling.", +1Evgeniy Stepanov2019-02-216-46/+0
| | | | | | Revert r354625, r354627 - multiple build failures. llvm-svn: 354629
* [hwasan,asan] Intercept vfork.Evgeniy Stepanov2019-02-216-0/+46
| | | | | | | | | | | | | | Summary: AArch64 only for now. Reviewers: vitalybuka, pcc Subscribers: srhines, kubamracek, mgorny, javed.absar, krytarowski, kristof.beyls, jdoerfert, #sanitizers, llvm-commits, kcc Tags: #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D58313 llvm-svn: 354625
OpenPOWER on IntegriCloud