summaryrefslogtreecommitdiffstats
path: root/compiler-rt/lib/sanitizer_common/sanitizer_win.cc
Commit message (Collapse)AuthorAgeFilesLines
* compiler-rt: Rename .cc file in lib/sanitizer_common to .cppNico Weber2019-07-311-1115/+0
| | | | | | | | | | | See https://reviews.llvm.org/D58620 for discussion, and for the commands I ran. In addition I also ran for f in $(svn diff | diffstat | grep .cc | cut -f 2 -d ' '); do rg $f . ; done and manually updated (many) references to renamed files found by that. llvm-svn: 367463
* Revert "Revert "[sanitizers] Don't use Windows Trace Logging on MinGW""Vlad Tsyrklevich2019-03-021-1/+7
| | | | | | | This reverts my orignal revert in r355250, I misread the buildbot logs. Volodymyr's commit in r355244 fixed the build. llvm-svn: 355251
* Revert "[sanitizers] Don't use Windows Trace Logging on MinGW"Vlad Tsyrklevich2019-03-021-7/+1
| | | | | | | This reverts commits r355236 and r355244, they broke the Linux sanitizer build. llvm-svn: 355250
* [sanitizers] Don't use Windows Trace Logging on MinGWMartin Storsjo2019-03-011-1/+7
| | | | | | | | | | | | | | | | | | | mingw-w64 currently is lacking the headers for this feature. Make the include lowercase at the same time. We consistently use lowercase for windows header includes, as windows itself is case insensitive, the SDK headers (in general, not necessarily considering this particular header) aren't consistent among themselves about what the proper canonical capitalization for headers are, and MinGW uses all lowercase names for the headers (as it is often used on case sensitive filesystems). In case mingw-w64 later gets this header, we can revert this (but keep the include lowercased). Differential Revision: https://reviews.llvm.org/D58765 llvm-svn: 355236
* [sanitizers] Explicitly use GetModuleFileNameW with wchar_tMartin Storsjo2019-03-011-1/+1
| | | | | | | | Alternatively we could define the string as TCHAR. Differential Revision: https://reviews.llvm.org/D58766 llvm-svn: 355180
* Add username to TODO comment in sanitizer to satisfy sanitizer lint check. NFCDouglas Yung2019-02-281-1/+1
| | | | llvm-svn: 355062
* [compiler-rt] Windows Trace Logging for error reports.Matthew G McGovern2019-02-271-0/+34
| | | | | | | | Adds option for collecting sanitixer dumps via trace logging. - Set log_to_syslog=1 to enable this output. - Consult https://aka.ms/windowstracelogging for details on use. llvm-svn: 355045
* [sanitizer] Fix fuchsia and windows build.Evgeniy Stepanov2019-02-061-2/+3
| | | | llvm-svn: 353261
* [sanitizer] Decorate /proc/self/maps better.Evgeniy Stepanov2019-02-061-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Refactor the way /proc/self/maps entries are annotated to support most (all?) posix platforms, with a special implementation for Android. Extend the set of decorated Mmap* calls. Replace shm_open with internal_open("/dev/shm/%s"). Shm_open is problematic because it calls libc open() which may be intercepted. Generic implementation has limits (max number of files under /dev/shm is 64K on my machine), which can be conceivably reached when sanitizing multiple programs at once. Android implemenation is essentially free, and enabled by default. The test in sanitizer_common is copied to hwasan and not reused directly because hwasan fails way too many common tests at the moment. Reviewers: pcc, vitalybuka Subscribers: srhines, kubamracek, jfb, llvm-commits, kcc Differential Revision: https://reviews.llvm.org/D57720 llvm-svn: 353255
* [ubsan] Make suppressions.cpp test pass for me on WindowsReid Kleckner2019-02-011-1/+7
| | | | | | | | | | | The test seems to be failing because the module suppression file contains a colon. I found that it was sufficient to just use the basename of the suppression file. While I was here, I noticed that we don't implement IsAbsolutePath for Windows, so I added it. llvm-svn: 352921
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* [xray] Detect MPROTECT and error out when it's enabled (on NetBSD)Michal Gorny2018-12-231-0/+4
| | | | | | | | | | Add a CheckMPROTECT() routine to detect when pax MPROTECT is enabled on NetBSD, and error xray out when it is. The solution is adapted from existing CheckASLR(). Differential Revision: https://reviews.llvm.org/D56049 llvm-svn: 350030
* [SanitizerCommon] Remove RenameFileEugene Leviant2018-12-031-4/+0
| | | | | | | | | This function seems to be no longer used by compiler-rt libraries Differential revision: https://reviews.llvm.org/D55123 llvm-svn: 348140
* [sanitizer] Use "fast mmap" kernel flag for shadow memory on macOS 10.13.4+Kuba Mracek2018-11-061-0/+4
| | | | | | | | This speeds up process startup and teardown and also reduces lock contention when running multiple ASanified/TSanified processes simultaneously. Should greatly improve lit testing time. Differential Revision: https://reviews.llvm.org/D48445 llvm-svn: 346262
* [sanitizer] Add char **GetEnviron() on all other platformsVitaly Buka2018-11-061-0/+5
| | | | | | | | Subscribers: kubamracek, llvm-commits Differential Revision: https://reviews.llvm.org/D54165 llvm-svn: 346257
* [sanitizers] [windows] Use a linker directive pragma for psapiMartin Storsjo2018-10-101-0/+4
| | | | | | | | | | | | | This allows users of static libraries (such as ubsan) to link without knowing about this transitive dependency, if using the psapi functions that require linking to a separate psapi library. Since Windows 7, these functions (EnumProcessModules, GetModuleInformation, GetProcessMemoryInfo) are remapped to K32- prefixed ones, available in kernel32.dll. Differential Revision: https://reviews.llvm.org/D53012 llvm-svn: 344126
* [asan/win] Use SRW locks to fix a race in BlockingMutexReid Kleckner2018-07-301-28/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Before my change, BlockingMutex used Windows critial sections. Critical sections can only be initialized by calling InitializeCriticalSection, dynamically. The primary sanitizer allocator expects to be able to reinterpret zero initialized memory as a BlockingMutex and immediately lock it. RegionInfo contains a mutex, and it placement new is never called for it. These objects are accessed via: RegionInfo *GetRegionInfo(uptr class_id) const { DCHECK_LT(class_id, kNumClasses); RegionInfo *regions = reinterpret_cast<RegionInfo *>(SpaceEnd()); return &regions[class_id]; } The memory comes from the OS without any other initialization. For various reasons described in the comments, BlockingMutex::Lock would check if the object appeared to be zero-initialized, and it would lazily call the LinkerInitialized constructor to initialize the critical section. This pattern is obviously racy, and the code had a bunch of FIXMEs about it. The best fix here is to use slim reader writer locks, which can start out zero-initialized. They are available starting in Windows Vista. I think it's safe to go ahead and use them today. Reviewers: kcc, vitalybuka Subscribers: kubamracek, llvm-commits Differential Revision: https://reviews.llvm.org/D49893 llvm-svn: 338331
* sanitizers: consistently check result of MmapFixedNoReserveDmitry Vyukov2018-07-201-3/+5
| | | | | | | | | | | | | | | | MmapFixedNoReserve does not terminate process on failure. Failure to check its result and die will always lead to harder to debug crashes later in execution. This was observed in Go processes due to some address space conflicts. Consistently check result of MmapFixedNoReserve. While we are here also add warn_unused_result attribute to prevent such bugs in future and change return type to bool as that's what all callers want. Reviewed in https://reviews.llvm.org/D49367 llvm-svn: 337531
* [TSan] Fix madvise(MADV_NOHUGEPAGE) for meta shadow memoryAlex Shlyapnikov2018-06-131-2/+4
| | | | | | | | | | | | | | | | Summary: Move madvise(MADV_NOHUGEPAGE) for the meta shadow memory after the meta shadow memory is mapped (currently it silently fails with ENOMEM). Add a diagnostic message to detect similar problems in the future. Reviewers: dvyukov Subscribers: kubamracek, delcypher, #sanitizers, llvm-commits Differential Revision: https://reviews.llvm.org/D48097 llvm-svn: 334624
* Introduce CheckASLR() in sanitizersKamil Rytarowski2018-06-051-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: At least the ASan, MSan, TSan sanitizers require disabled ASLR on a NetBSD. Introduce a generic CheckASLR() routine, that implements a check for the current process. This flag depends on the global or per-process settings. There is no simple way to disable ASLR in the build process from the level of a sanitizer or during the runtime execution. With ASLR enabled sanitizers that operate over the process virtual address space can misbehave usually breaking with cryptic messages. This check is dummy for !NetBSD. Sponsored by <The NetBSD Foundation> Reviewers: vitalybuka, joerg Reviewed By: vitalybuka Subscribers: cryptoad, kubamracek, llvm-commits, #sanitizers Tags: #sanitizers Differential Revision: https://reviews.llvm.org/D47442 llvm-svn: 333985
* [sanitizer] Replace InternalScopedBuffer with InternalMmapVectorVitaly Buka2018-05-071-1/+1
| | | | llvm-svn: 331618
* Fix clang-cl warnings in compiler-rtReid Kleckner2018-04-231-2/+2
| | | | | | | | | The profile library was missing some includes and was erroneously using ftruncate. WinASan was using `= {0}` to initialize structs, which creates -Wmissing-field-initializers and -Wmissing-braces warnings with clang. Use `= {}` instead, since this is C++. llvm-svn: 330616
* [sanitizer] Minor refactor of some ReservedAddressRange functionsKostya Kortchinsky2018-04-191-13/+6
| | | | | | | | | | | | | | | | | | | Summary: Some of the functions had spurious conditional statements and checks, and some intermediary variables that I feel made the code more complicated than it needs to be. Also, when unmapping the whole range, the range size would be 0, but the base was set to the address of the end of the range, which sounds prone to error. I think nulling out the base in this scenario is a better way to go. Reviewers: alekseyshl, flowerhack Reviewed By: alekseyshl Subscribers: kubamracek, delcypher, #sanitizers, llvm-commits Differential Revision: https://reviews.llvm.org/D45775 llvm-svn: 330355
* [sanitizer] Split stacktrace/symbolizer: Windows unwindKostya Kortchinsky2018-04-041-51/+0
| | | | | | | | | | | | | | | | | | | Summary: The purpose of this set of changes is to separate stackframe/symbolizer support into their own RT within sanitizer_common. Sanitizers with no use for those could then be built without the extraneous dependencies pulled in by the default visibility interface functions. I am aiming to do small changes for specific platforms. In this one, we split the unwind functions from sanitizer_win.cc into their own sanitizer_unwind_win.cc. Reviewers: alekseyshl, rnk Reviewed By: alekseyshl, rnk Subscribers: delcypher, #sanitizers, kubamracek, mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D44799 llvm-svn: 329204
* [sanitizer] Remove empty Symbolizer PrepareForSandboxingKostya Kortchinsky2018-04-031-2/+1
| | | | | | | | | | | | | | | | | | | | | | | Summary: `Symbolizer::PrepareForSandboxing` is empty for all platforms and apparently has been for a while (D10213). Remove it, and shuffle things around so that the platform specific code is now in `PlatformPrepareForSandboxing`. This allows to have one less symbolizer dependency in a common file, which helps for the upcoming split. Also remove `SymbolizerPrepareForSandboxing` in tsan_go which appears to not be used anywhere. Reviewers: alekseyshl, eugenis, dvyukov, mcgrathr Reviewed By: alekseyshl Subscribers: kubamracek, delcypher, llvm-commits, #sanitizers Differential Revision: https://reviews.llvm.org/D44953 llvm-svn: 329094
* [asan] Be more careful and verbose when allocating dynamic shadow memoryKuba Mracek2018-02-261-1/+2
| | | | | | | | 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] Implement GetRSS on WindowsKostya Kortchinsky2018-02-131-1/+4
| | | | | | | | | | | | | | | | | | Summary: Pretty straightforward, returning the `WorkingSetSize` of a `PROCESS_MEMORY_COUNTERS` structure. AFAIU, `GetProcessMemoryInfo` is in `kernel32.lib` for Windows 7 and above. Support for earlier Windows versions would require `psapi.lib`, but I don't think those are supported by ASan? Reviewers: alekseyshl, rnk, vitalybuka Reviewed By: vitalybuka Subscribers: vitalybuka, kubamracek, delcypher, llvm-commits, #sanitizers Differential Revision: https://reviews.llvm.org/D42822 llvm-svn: 325020
* [sanitizer] Implement NanoTime & MonotonicNanoTime for WindowsKostya Kortchinsky2018-02-011-4/+11
| | | | | | | | | | | | | | | | | | | | | | | | Summary: Implement `MonotonicNanoTime` using `QueryPerformanceCounter`. This function is used by Scudo & the 64-bit Primary allocator. Implementing it now means that the release-to-OS mechanism of the Primary will kick in (it never did since the function returned 0 always), but `ReleaseMemoryPagesToOS` is still not currently implemented for Windows. Performance wise, this adds a syscall & a 64-bit division per call to `MonotonicNanoTime` so the impact might not be negligible, but I don't think there is a way around it. Reviewers: rnk, alekseyshl, amccarth Reviewed By: alekseyshl, amccarth Subscribers: amccarth, flowerhack, kubamracek, delcypher, llvm-commits, #sanitizers Differential Revision: https://reviews.llvm.org/D42579 llvm-svn: 324011
* [sanitizer] Implement GetNumberOfCPUs for WindowsKostya Kortchinsky2018-01-251-2/+3
| | | | | | | | | | | | | | | | | Summary: Implement `GetNumberOfCPUs` using `GetNativeSystemInfo`. The only consummer of this function is Scudo which is not functional on Windows yet. Reviewers: rnk, zturner Reviewed By: zturner Subscribers: zturner, kubamracek, delcypher, #sanitizers, llvm-commits Differential Revision: https://reviews.llvm.org/D42547 llvm-svn: 323462
* [sanitizer] Introduce a vDSO aware timing functionKostya Kortchinsky2017-12-131-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | 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-4/+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/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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/+5
| | | | | | | | | | | | | | | | | | | 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
* [asan] Use dynamic shadow on 32-bit Android, try 2.Evgeniy Stepanov2017-11-201-0/+4
| | | | | | | | | | | | | | | | 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-4/+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
* [sanitizer] Update scudo to use new APIKostya Kortchinsky2017-11-131-0/+4
| | | | | | | | | | | | | | | | | | | Summary: The ScudoAllocator uses a SecondaryHeader to keep track of the size and base address of each mmap'd chunk. This aligns well with what the ReservedAddressRange is trying to do. This changeset converts the scudo allocator from using the MmapNoAccess/MmapFixed APIs to the ReservedAddressRange::Init and ::Map APIs. In doing so, it replaces the SecondayHeader struct with the ReservedAddressRange object. This is part 3 of a 4 part changeset; part 1 https://reviews.llvm.org/D39072 and part 2 https://reviews.llvm.org/D38592 Reviewers: alekseyshl, mcgrathr, cryptoad, phosek Reviewed By: cryptoad Subscribers: llvm-commits, cryptoad, kubamracek Differential Revision: https://reviews.llvm.org/D38593 llvm-svn: 318080
* [asan] Use dynamic shadow on 32-bit Android.Evgeniy Stepanov2017-11-101-0/+4
| | | | | | | | | | | | | | | | | | | 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] Revert rL317822Kostya Kortchinsky2017-11-091-5/+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/+5
| | | | | | | | | | | | | | 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-5/+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/+5
| | | | | | | | | | | | | | 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-5/+5
| | | | | | | | | | | | | | | | | | | | | 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
* Fix warning + death test + failing test on Windows (D39072).Kostya Kortchinsky2017-10-301-2/+2
| | | | | | | | | | | | | | Summary: Fixes https://reviews.llvm.org/D39072 Reviewers: cryptoad Reviewed By: cryptoad Subscribers: kubamracek Differential Revision: https://reviews.llvm.org/D39427 llvm-svn: 316943
* [sanitizer] Fixing an error introduced in D39072Kostya Kortchinsky2017-10-301-1/+1
| | | | | | | | | | | | | | Summary: This should fix the Windows bots after D39072. Reviewers: alekseyshl, flowerhack Reviewed By: flowerhack Subscribers: llvm-commits, kubamracek Differential Revision: https://reviews.llvm.org/D39426 llvm-svn: 316937
* Introduce ReservedAddressRange to sanitizer_common.Kostya Kortchinsky2017-10-301-0/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix clang warnings in winasan codeReid Kleckner2017-10-301-3/+3
| | | | | | There are two instances of -Wcast-qual and one of -Wsign-compare. llvm-svn: 316930
* Revert r315533 "Reland "[sanitizer] Introduce ReservedAddressRange to ↵Hans Wennborg2017-10-121-37/+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/+37
| | | | | | | | | | | | | | | | | | | | | | 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
OpenPOWER on IntegriCloud