summaryrefslogtreecommitdiffstats
path: root/compiler-rt/lib/sanitizer_common/sanitizer_win.cc
Commit message (Collapse)AuthorAgeFilesLines
...
* tsan: fix windows buildDmitry Vyukov2016-10-281-0/+2
| | | | | | | | | | | | | | | | | | | | | Currently fails with: C:\workdir\compiler-rt\lib\tsan\go>gcc -c -o race_windows_amd64.syso gotsan.cc -I..\rtl -I..\.. -I..\..\sanitizer_common -I..\..\..\include -m64 -Wall -fno-exceptions -fno-rtti -DSANITIZER_GO -Wno-error=at tributes -Wno-attributes -Wno-format -Wno-maybe-uninitialized -DSANITIZER_DEBUG=0 -O3 -fomit-frame-pointer -std=c++11 gotsan.cc:9229:0: warning: ignoring #pragma comment [-Wunknown-pragmas] #pragma comment(linker, "/alternatename:__sanitizer_print_memory_profile=__sanitizer_default_print_memory_profile") // NOLINT ^ gotsan.cc: In function 'void __sanitizer_print_memory_profile(int)': gotsan.cc:9226:17: error: redefinition of 'void __sanitizer_print_memory_profile(int)' extern "C" void __sanitizer_print_memory_profile(int top_percent) {} ^ gotsan.cc:6898:6: note: 'void __sanitizer_print_memory_profile(int)' previously defined here void __sanitizer_print_memory_profile(int top_percent) { Remove __sanitizer_print_memory_profile from Go build, it is not needed. llvm-svn: 285400
* [compiler-rt] Add support for the dynamic shadow allocationEtienne Bergeron2016-09-301-0/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch is adding support for dynamic shadow allocation. This is a merge and re-commit of the following patches. ``` [compiler-rt] Fix Asan build on Android https://reviews.llvm.org/D24768 [compiler-rt] Add support for the dynamic shadow allocation https://reviews.llvm.org/D23363 ``` This patch needed to re-land at the same time: ``` [asan] Support dynamic shadow address instrumentation https://reviews.llvm.org/D23354 ``` Reviewers: rnk, zaks.anna Subscribers: tberghammer, danalbert, kubabrecka, dberris, chrisha, llvm-commits Differential Revision: https://reviews.llvm.org/D25104 llvm-svn: 282882
* revert 282085, 281909, they broke 32-bit dynamic ASan and the ↵Nico Weber2016-09-211-20/+0
| | | | | | sanitizer-windows bot llvm-svn: 282096
* [compiler-rt] Add support for the dynamic shadow allocationEtienne Bergeron2016-09-191-0/+20
| | | | | | | | | | | | | | | | | | | | | | Summary: This patch is adding the needed code to compiler-rt to support dynamic shadow. This is to support this patch: https://reviews.llvm.org/D23354 It's adding support for using a shadow placed at a dynamic address determined at runtime. The dynamic shadow is required to work on windows 64-bits. Reviewers: rnk, kcc, vitalybuka Subscribers: kubabrecka, dberris, llvm-commits, chrisha Differential Revision: https://reviews.llvm.org/D23363 llvm-svn: 281909
* Really fix the Windows sanitizer buildReid Kleckner2016-09-151-0/+12
| | | | | | | | | | Don't list __sanitizer_print_memory profile as an INTERFACE_FUNCTION. It is not exported by ASan; it is exported by user code. Move the weak definition from asan_win.cc to sanitizer_win.cc to fix the ubsan tests. llvm-svn: 281619
* [asan] first attempt at releasing free-d memory back to the system using ↵Kostya Serebryany2016-08-261-2/+2
| | | | | | madvise. Requires quite some tuning. llvm-svn: 279887
* Fix dumping of process module list and test itReid Kleckner2016-08-051-2/+2
| | | | | | I probably broke this a year ago in r243895. llvm-svn: 277842
* [compiler-rt] Fix memory allocator for dynamic address spaceEtienne Bergeron2016-08-041-2/+6
| | | | | | | | | | | | | | | | | | | | | | | Summary: The sanitizer allocators can works with a dynamic address space (i.e. specified with ~0ULL). Unfortunately, the code was broken on GetMetadata and GetChunkIdx. The current patch is moving the Win64 memory test to a dynamic address space. There is a migration to move every concept to a dynamic address space on windows. To have a better coverage, the unittest are now testing dynamic address space on other platforms too. Reviewers: rnk, kcc Subscribers: kubabrecka, dberris, llvm-commits, chrisha Differential Revision: https://reviews.llvm.org/D23170 llvm-svn: 277745
* [sanitizer] better allocator stats (with rss)Kostya Serebryany2016-07-211-0/+5
| | | | llvm-svn: 276343
* [compiler-rt] Fix broken SymInitialize unittestEtienne Bergeron2016-07-211-0/+2
| | | | | | | | | | | | | | | | Summary: By adding the initialisation of the symbolisation library (DbgHelp) we are swapping the order in which both warnings are produced. We can't use CHECK-NEXT as the dbghelp warning is multiline. Reviewers: rnk Subscribers: kubabrecka, llvm-commits, wang0109, chrisha Differential Revision: https://reviews.llvm.org/D22586 llvm-svn: 276228
* tsan: fix windows buildDmitry Vyukov2016-07-201-3/+3
| | | | | | It's only asan that installs vectored SEH handler to map memory lazily. llvm-svn: 276112
* revert https://reviews.llvm.org/D22393Etienne Bergeron2016-07-181-2/+0
| | | | | | It is breaking build 32-bit build bots. llvm-svn: 275816
* TestCase null_deref was failing in Win64:Etienne Bergeron2016-07-151-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | c:\lipo\work\asan\b_llvm>c:\lipo\work\asan\b_llvm\projects\compiler-rt\test\asan\X86_64WindowsConfig\TestCases\Output\null_deref.cc.tmp ================================================================= ==5488==ERROR: AddressSanitizer: access-violation on unknown address 0x000000000028 (pc 0x7ff701f91067 bp 0x000c8cf8fbf0 sp 0x000c8cf8fbb0 T0) ==5488==The signal is caused by a READ memory access. ==5488==Hint: address points to the zero page. #0 0x7ff701f91066 in NullDeref(int *) C:\lipo\work\asan\llvm\projects\compiler-rt\test\asan\TestCases\null_deref.cc:15:10 #1 0x8a0388830a67 (<unknown module>) The reason was symbols was not initilized. In fact, it was first inited with a call to stack.Print(), which calls WinSymbolizerTool::SymbolizePC, then InitializeDbgHelpIfNeeded(). Since the StackWalk was performed before the stack.Print(), stack frames where not gathered correctly. There should be a better place to initialize symbols. For now, this patch makes the test happy. Patch by Wei Wang Differential Revision: https://reviews.llvm.org/D22410 llvm-svn: 275580
* [compiler-rt] Fix missing frame with stackwalking on windows 64-bitsEtienne Bergeron2016-07-141-1/+1
| | | | | | | | | | | | Summary: Fix missing frame with stackwalking on windows 64-bits Reviewers: rnk Subscribers: llvm-commits, wang0109, kubabrecka, chrisha Differential Revision: https://reviews.llvm.org/D22358 llvm-svn: 275486
* [asan] Add exception handler to map memory on demand on Win64.Etienne Bergeron2016-07-111-3/+10
| | | | | | | | | | Memory will be committed on demand when exception happens while accessing shadow memeory region. Patch by: Wei Wang Differential Revision: http://reviews.llvm.org/D21942 llvm-svn: 275107
* [compiler-rt] Fix sanitizer memory allocator on win64.Etienne Bergeron2016-07-071-2/+4
| | | | | | | | | | | | | | | | | | | | | | | Summary: This patch is fixing unittests for sanitizer memory allocator. There was two issues: 1) The VirtualAlloc can't reserve twice a memory range. The memory space used by the SizeClass allocator is reserved with NoAccess and pages are commited on demand (using MmapFixedOrDie). 2) The address space is allocated using two VirtualAlloc calls. The first one for the memory space, the second one for the AdditionnalSpace (after). On windows, they need to be freed separately. Reviewers: rnk Subscribers: llvm-commits, wang0109, kubabrecka, chrisha Differential Revision: http://reviews.llvm.org/D21900 llvm-svn: 274772
* Use CreateFileA and add a FIXME to switch to the wide variantReid Kleckner2016-06-231-5/+6
| | | | | | | No functional change. Required to build with -DUNICODE, as is done in http://reviews.llvm.org/D21643 llvm-svn: 273571
* tsan: fix windows supportDmitry Vyukov2016-04-271-11/+9
| | | | | | | | | | | | | | UnmapOrDie used to do MEM_DECOMMIT and so worked on partial regions. But r263160 changed it to use MEM_RELEASE and MEM_RELEASE can only work with whole regions mapped by VirtualAlloc. This broke windows as: FATAL: ThreadSanitizer CHECK failed: gotsan.cc:8296 "((mbi.AllocationBase == addr && "Windows cannot unmap part of a previous mapping")) != (0)" (0x0, 0x0) Restore the previous behavior. llvm-svn: 267730
* tsan: fix windows buildDmitry Vyukov2016-04-271-1/+1
| | | | | warning: '__sanitizer::uptr __sanitizer::GetPreferredBase(const char*)' defined but not used llvm-svn: 267682
* [sanitizer] add a function MmapNoAccess that mmaps a protected region ↵Kostya Serebryany2016-04-231-0/+5
| | | | | | *somewhere*; use MmapNoAccess in the Allocator when SpaceBeg is not a constant. In this mode the allocator will be a bit more hardened llvm-svn: 267256
* [sanitizer] rename MmapNoAccess to MmapFixedNoAccess; NFCKostya Serebryany2016-04-221-1/+1
| | | | llvm-svn: 267253
* [sanitizer] On OS X, verify that interceptors work and abort if not, take 2Kuba Brecka2016-03-171-4/+0
| | | | | | | | | | On OS X 10.11+, we have "automatic interceptors", so we don't need to use DYLD_INSERT_LIBRARIES when launching instrumented programs. However, non-instrumented programs that load TSan late (e.g. via dlopen) are currently broken, as TSan will still try to initialize, but the program will crash/hang at random places (because the interceptors don't work). This patch adds an explicit check that interceptors are working, and if not, it aborts and prints out an error message suggesting to explicitly use DYLD_INSERT_LIBRARIES. TSan unit tests run with a statically linked runtime, where interceptors don't work. To avoid aborting the process in this case, the patch replaces `DisableReexec()` with a weak `ReexecDisabled()` function which is defined to return true in unit tests. Differential Revision: http://reviews.llvm.org/D18212 llvm-svn: 263695
* [Windows] Fix UnmapOrDie and MmapAlignedOrDieReid Kleckner2016-03-101-2/+75
| | | | | | | | | | | | | | | | | | | | | | | | | Now ASan can return virtual memory to the underlying OS. Portable sanitizer runtime code needs to be aware that UnmapOrDie cannot unmap part of previous mapping. In particular, this required changing how we implement MmapAlignedOrDie on Windows, which is what Allocator32 uses. The new code first attempts to allocate memory of the given size, and if it is appropriately aligned, returns early. If not, it frees the memory and attempts to reserve size + alignment bytes. In this region there must be an aligned address. We then free the oversized mapping and request a new mapping at the aligned address immediately after. However, a thread could allocate that virtual address in between our free and allocation, so we have to retry if that allocation fails. The existing thread creation stress test managed to trigger this condition, so the code isn't totally untested. Reviewers: samsonov Differential Revision: http://reviews.llvm.org/D17431 llvm-svn: 263160
* [Sanitizer] Introduce ListOfModules object and use it to replace ↵Alexey Samsonov2016-02-221-18/+11
| | | | | | | | | | | | | | | | | | | | GetListOfModules(). Summary: This removes the hard limit on the number of loaded modules (used to be 16K), and makes it easier to use LoadedModules w/o causing a memory leak: ListOfModules owns the modules, and makes sure to properly clean them in destructor. Remove filtering functionality that is only needed in one place (LSan). Reviewers: aizatsky Subscribers: llvm-commits, kcc Differential Revision: http://reviews.llvm.org/D17470 llvm-svn: 261554
* [WinASan] Fix page size and mmap granularity confusionReid Kleckner2016-02-181-4/+6
| | | | | | | | | | | We were erroneously reporting 16K as the page size on Windows because the code that does the shadow mapping was using page size instead of allocation granularity. After fixing that, we can resolve the FIXMEs in the Windows implementations of GetPageSize and GetMmapGranularity by calling GetSystemInfo instead of returning hard-coded, incorrect answers. llvm-svn: 261233
* [Windows] Fill in read/write information in SignalContextReid Kleckner2016-02-111-2/+11
| | | | | | Implements https://github.com/google/sanitizers/issues/653 llvm-svn: 260539
* [asan] Fix build on Windows and PowerPC.Evgeniy Stepanov2016-02-091-4/+4
| | | | llvm-svn: 260175
* [asan] Fix Windows build.Evgeniy Stepanov2016-02-081-3/+3
| | | | llvm-svn: 260167
* [asan] When catching a signal caused by a memory access, print if it's a ↵Kostya Serebryany2016-02-041-1/+4
| | | | | | READ or a WRITE. This touches win/mac files which I have not tested, if a win/mac bot fails I'll try to quick-fix llvm-svn: 259741
* [asan] Add iOS support.Anna Zaks2016-02-021-1/+1
| | | | llvm-svn: 259451
* [sanitizers] generating html report on coverage dumpMike Aizatsky2016-01-271-0/+2
| | | | | | | | Subscribers: tberghammer, danalbert, srhines Differential Revision: http://reviews.llvm.org/D16374 llvm-svn: 258999
* [sanitizers] extracted process management functionsMike Aizatsky2016-01-261-0/+14
| | | | | | Differential Revision: http://reviews.llvm.org/D16546 llvm-svn: 258849
* Revert "[sanitizers] extracted process management functions"Mike Aizatsky2016-01-251-12/+0
| | | | | | This reverts commit e5b34d5a2bf4c882bc647dd26a8cea2adc76f63c. llvm-svn: 258713
* [sanitizers] extracted process management functionsMike Aizatsky2016-01-251-0/+12
| | | | | | Differential Revision: http://reviews.llvm.org/D16542 llvm-svn: 258710
* [asan] Optionally print reproducer cmdline in ASan reports.Maxim Ostapenko2016-01-181-0/+5
| | | | | | Differential Revision: http://reviews.llvm.org/D16070 llvm-svn: 258037
* Unbreak Windows build.Peter Collingbourne2016-01-151-1/+1
| | | | llvm-svn: 257860
* [tsan] Use re-exec method to enable interceptors on older versions of OS XKuba Brecka2015-12-031-0/+8
| | | | | | | | In AddressSanitizer, we have the MaybeReexec method to detect when we're running without DYLD_INSERT_LIBRARIES (in which case interceptors don't work) and re-execute with the environment variable set. On OS X 10.11+, this is no longer necessary, but to have ThreadSanitizer supported on older versions of OS X, let's use the same method as well. This patch moves the implementation from `asan/` into `sanitizer_common/`. Differential Revision: http://reviews.llvm.org/D15123 llvm-svn: 254600
* [asan] Fix the deadlocks introduced by "On OS X, log reports to syslog and ↵Anna Zaks2015-11-201-2/+3
| | | | | | | | | | | | os_trace" commit [asan] On OS X, log reports to syslog and os_trace, has been reverted in r252076 due to deadlocks on earlier versions of OS X. Alexey has also noticed deadlocks in some corner cases on Linux. This patch, if applied on top of the logging patch (http://reviews.llvm.org/D13452), addresses the known deadlock issues. (This also proactively removes the color escape sequences from the error report buffer since we have to copy the buffer anyway.) Differential Revision: http://reviews.llvm.org/D14470 llvm-svn: 253689
* tsan: fix windows Go buildDmitry Vyukov2015-11-121-1/+1
| | | | | | | | | | | Go build does not link in whatever library provides these symbols: # runtime/race race_windows_amd64.syso:gotsan.cc:(.text+0x578f): undefined reference to `__sanitizer::DumpProcessMap()' race_windows_amd64.syso:gotsan.cc:(.text+0xee33): undefined reference to `EnumProcessModules' race_windows_amd64.syso:gotsan.cc:(.text+0xeeb9): undefined reference to `GetModuleInformation' llvm-svn: 252922
* tsan: fix windows Go buildDmitry Vyukov2015-11-121-0/+2
| | | | | | CompareModulesBase is an unused function. llvm-svn: 252907
* [Sanitizer] Use ReportMmapFailureAndDie() in all applicable mmap variants on ↵Alexey Samsonov2015-11-051-1/+1
| | | | | | Posix. llvm-svn: 252121
* [compiler-rt] [sanitizers] Add VMA size check at runtimeAdhemerval Zanella2015-09-111-0/+4
| | | | | | | | | This patch adds a runtime check for asan, dfsan, msan, and tsan for architectures that support multiple VMA size (like aarch64). Currently the check only prints a warning indicating which is the VMA built and expected against the one detected at runtime. llvm-svn: 247413
* Same fix as r244908 for sanitizer_win.cc instead of asan_win.ccReid Kleckner2015-08-131-1/+1
| | | | | | | I forgot to audit lib/sanitizer_common for the same issue. This fixes writing out coverage files on exit. llvm-svn: 244910
* [windows] Fix deadlock on mmap failure due to CHECK recursionReid Kleckner2015-08-121-6/+2
| | | | | | | | | | | | | | | | | | | Summary: Printing a stacktrace acquires a spinlock, and the sanitizer spinlocks aren't re-entrant. Avoid the problem by reusing the logic we already have on Posix. This failure mode is already exercised by the existing mmap_limit_mb.cc test case. It will be enabled in a forthcoming change, so I didn't add standalone tests for this change. Reviewers: samsonov Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D11999 llvm-svn: 244840
* [Windows] Implement FileExists, ReadFromFile, and FindPathToBinaryReid Kleckner2015-08-101-17/+23
| | | | | | | | | | | | Summary: These are needed to talk to llvm-symbolizer on Windows. Reviewers: samsonov Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D11920 llvm-svn: 244533
* Try to fix sanitizer_win.cc compile error on 64-bit after r243895Hans Wennborg2015-08-051-1/+8
| | | | llvm-svn: 244077
* [asan] Print VAs instead of RVAs for module offsets on WindowsReid Kleckner2015-08-031-10/+87
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is consistent with binutils and ASan behavior on other platforms, and makes it easier to use llvm-symbolizer with WinASan. The --relative-address flag to llvm-symbolizer is also no longer needed. An RVA is a "relative virtual address", meaning it is the address of something inside the image minus the base of the mapping at runtime. A VA in this context is an RVA plus the "preferred base" of the module, and not a real runtime address. The real runtime address of a symbol will equal the VA iff the module is loaded at its preferred base at runtime. On Windows, the preferred base is stored in the ImageBase field of one of the PE file header, and this change adds the necessary code to extract it. On Linux, this offset is typically included in program and section headers of executables. ELF shared objects typically use a preferred base of zero, meaning the smallest p_vaddr field in the program headers is zero. This makes it so that PIC and PIE module offsets come out looking like RVAs, but they're actually VAs. The difference between them simply happens to be zero. Reviewers: samsonov, majnemer Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D11681 llvm-svn: 243895
* Re-commit r243686 - [Sanitizers] [Bug 24151] Generalize type of offset in ↵Daniel Sanders2015-07-311-1/+1
| | | | | | | | | internal_mmap The builder remains broken in the same way without this patch so this patch is innocent. llvm-svn: 243744
* Revert r243686 - [Sanitizers] [Bug 24151] Generalize type of offset in ↵Daniel Sanders2015-07-311-1/+1
| | | | | | | | | internal_mmap It's implicated in a buildbot failure and while the failure looks unrelated, this commit is the only probably candidate in the blamelist. llvm-svn: 243740
* [Sanitizers] [Bug 24151] Generalize type of offset in internal_mmapDaniel Sanders2015-07-301-1/+1
| | | | | | | | | | | | | | | | Summary: Using u64 as type for offset changes its value, changing starting address for map in file. This patch solves Bug 24151, which raises issue while mapping file in mips32. Patch by Mohit Bhakkad Reviewers: dsanders, kcc Subscribers: hans, llvm-commits, samsonov, nitesh.jain, sagar, bhushan, jaydeep Differential Revision: http://reviews.llvm.org/D11588 llvm-svn: 243686
OpenPOWER on IntegriCloud