summaryrefslogtreecommitdiffstats
path: root/compiler-rt/lib/sanitizer_common/tests
Commit message (Collapse)AuthorAgeFilesLines
...
* [sanitizer] Guard call to internal_lseek when SANITIZER_MAC is trueFrancis Visoiu Mistrih2018-06-181-1/+1
| | | | | | | | | | r334881 breaks macOS bots because internal_lseek is not defined (neither used on macOS): http://green.lab.llvm.org/green/job/clang-stage1-configure-RA/46240/consoleFull. See discussion from r334881: https://reviews.llvm.org/rL334881 llvm-svn: 334944
* [sanitizer_common] Fix windows build caused by r334881Fangrui Song2018-06-161-1/+3
| | | | llvm-svn: 334884
* [sanitizer_common] Use O_TRUNC for WrOnly access mode.Fangrui Song2018-06-161-0/+6
| | | | | | | | | | | | Summary: Otherwise if the file existed and was larger than the write size before the OpenFile call, the file will not be truncated and contain garbage in trailing bytes. Reviewers: glider, kcc, vitalybuka Subscribers: kubamracek, delcypher, llvm-commits, #sanitizers Differential Revision: https://reviews.llvm.org/D48250 llvm-svn: 334881
* [sanitizer] Don't use internal_unlink on WindowsVitaly Buka2018-06-071-8/+12
| | | | llvm-svn: 334152
* [sanitizer] Replace deprecated mktemp with mkstempVitaly Buka2018-06-061-1/+1
| | | | llvm-svn: 334138
* [sanitizer] Cleanup ReadFileToVector and ReadFileToBufferVitaly Buka2018-06-062-3/+63
| | | | | | | | | | | | | | | Summary: Added unit-test. Fixed behavior of max_len argument. Call read syscall with all available buffer, not just a page. Reviewers: eugenis Subscribers: kubamracek, mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D46618 llvm-svn: 334130
* [sanitizer] Use all available rounded up capacityVitaly Buka2018-05-091-0/+6
| | | | | | | | | | Reviewers: eugenis Subscribers: kubamracek, llvm-commits Differential Revision: https://reviews.llvm.org/D46617 llvm-svn: 331940
* [sanitizer] Use tid_t in ThreadListerVitaly Buka2018-05-091-19/+18
| | | | llvm-svn: 331921
* [sanitizer] Cleanup sorting functionsVitaly Buka2018-05-091-6/+6
| | | | llvm-svn: 331915
* [sanitizer] Fix InternalMmapVectorNoCtor reserve and resizeVitaly Buka2018-05-081-0/+23
| | | | | | | Remap on reserve of more than the current size. Don't remap on downsize. llvm-svn: 331784
* [sanitizer] Add InternalMmapVector::swapVitaly Buka2018-05-081-0/+18
| | | | llvm-svn: 331736
* [sanitizer] Simplify ThreadLister interfaceVitaly Buka2018-05-071-15/+8
| | | | | | | | | | Reviewers: eugenis Subscribers: kubamracek, llvm-commits Differential Revision: https://reviews.llvm.org/D46516 llvm-svn: 331701
* [sanitizer] s/TestOnlyInit/Init for the allocator ByteMap (NFC)Kostya Kortchinsky2018-05-071-2/+2
| | | | | | | | | | | | | | | | | Summary: The `TestOnlyInit` function of `{Flat,TwoLevel}ByteMap` seems to be a misnomer since the function is used outside of tests as well, namely in `SizeClassAllocator32::Init`. Rename it to `Init` and update the callers. Reviewers: alekseyshl, vitalybuka Reviewed By: vitalybuka Subscribers: kubamracek, delcypher, #sanitizers, llvm-commits Differential Revision: https://reviews.llvm.org/D46408 llvm-svn: 331662
* [sanitizer] Add operator== and operator!= for InternalMmapVectorNoCtorVitaly Buka2018-05-071-0/+23
| | | | llvm-svn: 331619
* [sanitizer] Replace InternalScopedBuffer with InternalMmapVectorVitaly Buka2018-05-071-2/+2
| | | | llvm-svn: 331618
* [sanitizer] Remove reserving constructor from InternalMmapVectorVitaly Buka2018-05-072-4/+6
| | | | llvm-svn: 331617
* [sanitizer] Make InternalScopedBuffer::size() behavior similar to vector.Vitaly Buka2018-05-071-2/+2
| | | | llvm-svn: 331612
* [sanitizer] More dead code removalKostya Kortchinsky2018-04-241-17/+0
| | | | | | | | | | | | | | | | | | Summary: The following functions are only used in tests: `SetEnv`, `SanitizerSetThreadName`, `SanitizerGetThreadName`. I don't think they are going to be used in the future, and I propose to get rid of them, and associated tests and include. Reviewers: alekseyshl, eugenis, vitalybuka Reviewed By: vitalybuka Subscribers: dvyukov, vitalybuka, kubamracek, delcypher, llvm-commits, #sanitizers Differential Revision: https://reviews.llvm.org/D45838 llvm-svn: 330724
* [Sanitizer] Internal Printf string width + left-justify.Alex Shlyapnikov2018-04-231-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: Example: Printf("%-5s", "123"); should yield: '123 ' In case Printf's requested string field width is larger than the string argument length, the resulting string should be padded up to the requested width. For the simplicity sake, implementing left-justified (right padding) only. Reviewers: eugenis Subscribers: kubamracek, delcypher, #sanitizers, llvm-commits Differential Revision: https://reviews.llvm.org/D45906 llvm-svn: 330643
* Revert "[Sanitizer] Internal Printf string precision argument + padding."Alex Shlyapnikov2018-04-201-7/+2
| | | | | | | | | This reverts commit r330458. There are existing code using string precision as 'max len', need more work. llvm-svn: 330476
* [Sanitizer] Internal Printf string precision argument + padding.Alex Shlyapnikov2018-04-201-2/+7
| | | | | | | | | | | | | | | | | | | | | | Summary: Example: Printf("%.*s", 5, "123"); should yield: '123 ' In case Printf's requested string precision is larger than the string argument, the resulting string should be padded up to the requested precision. For the simplicity sake, implementing right padding only. Reviewers: eugenis Subscribers: kubamracek, delcypher, #sanitizers, llvm-commits Differential Revision: https://reviews.llvm.org/D45844 llvm-svn: 330458
* [sanitizer] Split Symbolizer/StackTraces from core RTSanitizerCommonKostya Kortchinsky2018-04-161-3/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Host symbolizer & stacktraces related code in their own RT: `RTSanitizerCommonSymbolizer`, which is "libcdep" by nature. Symbolizer & stacktraces specific code that used to live in common files is moved to a new file `sanitizer_symbolizer_report.cc` as is. The purpose of this is the enforce a separation between code that relies on symbolization and code that doesn't. This saves the inclusion of spurious code due to the interface functions with default visibility, and the extra data associated. The following sanitizers makefiles were modified & tested locally: - dfsan: doesn't require the new symbolizer RT - esan: requires it - hwasan: requires it - lsan: requires it - msan: requires it - safestack: doesn't require it - xray: doesn't require it - tsan: requires it - ubsan: requires it - ubsan_minimal: doesn't require it - scudo: requires it (but not for Fuchsia that has a minimal runtime) This was tested locally on Linux, Android, Fuchsia. Reviewers: alekseyshl, eugenis, dberris, kubamracek, vitalybuka, dvyukov, mcgrathr Reviewed By: alekseyshl, vitalybuka Subscribers: srhines, kubamracek, mgorny, krytarowski, delcypher, llvm-commits, #sanitizers Differential Revision: https://reviews.llvm.org/D45457 llvm-svn: 330131
* [sanitizer] Fix __sanitizer::Vector::Resize vectorVitaly Buka2018-04-131-0/+9
| | | | | | | | | | | | | | | | Implemented downsizing Patch by Oleg Doronin Reviewers: kcc, vitalybuka Reviewed By: kcc, vitalybuka Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D45605 llvm-svn: 330049
* [sanitizer] Replace cast with unsigned literals in testsVitaly Buka2018-04-131-4/+4
| | | | llvm-svn: 330048
* Revert "[compiler-rt] Change std::sort to llvm::sort in response to r327219"Mandeep Singh Grang2018-03-202-3/+3
| | | | | | This reverts commit 2ee210e1963e03aacc0f71c50e4994bb5c66586e. llvm-svn: 327936
* [compiler-rt] Change std::sort to llvm::sort in response to r327219Mandeep Singh Grang2018-03-202-3/+3
| | | | | | | | | | | | | | | | | | | Summary: r327219 added wrappers to std::sort which randomly shuffle the container before sorting. This will help in uncovering non-determinism caused due to undefined sorting order of objects having the same key. To make use of that infrastructure we need to invoke llvm::sort instead of std::sort. Reviewers: kcc, rsmith, RKSimon, eugenis Reviewed By: RKSimon Subscribers: efriedma, kubamracek, dberris, #sanitizers, llvm-commits Differential Revision: https://reviews.llvm.org/D44360 llvm-svn: 327929
* [Sanitizers] Make common allocator agnostic to failure handling modes.Alex Shlyapnikov2018-01-171-10/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Make common allocator agnostic to failure handling modes and move the decision up to the particular sanitizer's allocator, where the context is available (call stack, parameters, return nullptr/crash mode etc.) It simplifies the common allocator and allows the particular sanitizer's allocator to generate more specific and detailed error reports (which will be implemented later). The behavior is largely the same, except one case, the violation of the common allocator's check for "size + alignment" overflow is now reportied as OOM instead of "bad request". It feels like a worthy tradeoff and "size + alignment" is huge in this case anyway (thus, can be interpreted as not enough memory to satisfy the request). There's also a Report() statement added there. Reviewers: eugenis Subscribers: kubamracek, llvm-commits, #sanitizers Differential Revision: https://reviews.llvm.org/D42198 llvm-svn: 322784
* [Sanitizers, test] Fix sanitizer tests on Solaris (PR 33274)Kamil Rytarowski2018-01-171-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch (on top of the previous two (https://reviews.llvm.org/D40898 and https://reviews.llvm.org/D40899) complete the compiler-rt side of the the Solaris sanitizer port. It contains the following sets of changes: * For the time being, the port is for 32-bit x86 only, so reject the various tests on x86_64. * When compiling as C++, <setjmp.h> resp. <iso/setjmp_iso.h> only declares _setjmp and _longjmp inside namespace std. * MAP_FILE is a Windows feature. While e.g. Linux <sys/mman.h> provides a no-op compat define, Solaris does not. * test/asan/TestCases/Posix/coverage.cc was initially failing like this: /vol/gcc/src/llvm/llvm/local/projects/compiler-rt/lib/sanitizer_common/scripts/sancov.py: 4 files merged; 2 PCs total rm: cannot remove '/var/gcc/llvm/local/projects/compiler-rt/test/asan/I386SunOSConfig/TestCases/Posix/Output/coverage': Invalid argument Further digging revealed that the rm was trying to remove the running test's working directory which failed as observed. cd'ing out of the dir before let the test pass. * Two tests needed a declaration of alloca. I've now copied the existing code from test/asan/TestCases/alloca_constant_size.cc, but it may be more profitable and maintainable to have a common testsuite header where such code is collected. * Similarly, Solaris' printf %p format doesn't include the leading 0x. * In test/asan/TestCases/malloc-no-intercept.c, I had to undef __EXTENSIONS__ (predefined by clang for no apparent reason) to avoid conflicting declarations for memalign. * test/ubsan/TestCases/Float/cast-overflow.cpp has different platform dependent ways to define BYTE_ORDER and friends. Why not just use __BYTE_ORDER__ and friends as predefined by clang and gcc? Patch by Rainer Orth. Reviewers: kcc, alekseyshl Reviewed By: alekseyshl Subscribers: srhines, kubamracek, mgorny, krytarowski, fedor.sergeev, JDevlieghere, llvm-commits, #sanitizers Tags: #sanitizers Differential Revision: https://reviews.llvm.org/D40900 llvm-svn: 322635
* Move __tsan::Vector to __sanitizerKamil Rytarowski2017-12-042-1/+44
| | | | | | | | | | | | | | | | | | | | | Summary: The low-fat STL-like vector container will be reused in MSan. It is needed to implement an atexit(3) interceptor on NetBSD/amd64 in MSan. Sponsored by <The NetBSD Foundation> Reviewers: joerg, dvyukov, eugenis, vitalybuka, kcc Reviewed By: dvyukov Subscribers: kubamracek, mgorny, llvm-commits, #sanitizers Tags: #sanitizers Differential Revision: https://reviews.llvm.org/D40726 llvm-svn: 319650
* Fix warning + death test + failing test on Windows (D39072).Kostya Kortchinsky2017-10-301-7/+5
| | | | | | | | | | | | | | Summary: Fixes https://reviews.llvm.org/D39072 Reviewers: cryptoad Reviewed By: cryptoad Subscribers: kubamracek Differential Revision: https://reviews.llvm.org/D39427 llvm-svn: 316943
* Introduce ReservedAddressRange to sanitizer_common.Kostya Kortchinsky2017-10-301-0/+67
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-62/+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/+62
| | | | | | | | | | | | | | | | | | | | | | 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-62/+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/+62
| | | | | | | | | | | | | | | | | | | | | | 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
* [Sanitizer] Disable compact size class tests on AndroidAlex Shlyapnikov2017-09-271-0/+2
| | | | | | | Fixing test failure on Android introduced in D38245. Compact size class maps defined there are not to be used on Android. llvm-svn: 314318
* [Sanitizers] Allocator: new "release memory to OS" implementationAlex Shlyapnikov2017-09-271-0/+275
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The current implementation of the allocator returning freed memory back to OS (controlled by allocator_release_to_os_interval_ms flag) requires sorting of the free chunks list, which has two major issues, first, when free list grows to millions of chunks, sorting, even the fastest one, is just too slow, and second, sorting chunks in place is unacceptable for Scudo allocator as it makes allocations more predictable and less secure. The proposed approach is linear in complexity (altough requires quite a bit more temporary memory). The idea is to count the number of free chunks on each memory page and release pages containing free chunks only. It requires one iteration over the free list of chunks and one iteration over the array of page counters. The obvious disadvantage is the allocation of the array of the counters, but even in the worst case we support (4T allocator space, 64 buckets, 16 bytes bucket size, full free list, which leads to 2 bytes per page counter and ~17M page counters), requires just about 34Mb of the intermediate buffer (comparing to ~64Gb of actually allocated chunks) and usually it stays under 100K and released after each use. It is expected to be a relatively rare event, releasing memory back to OS, keeping the buffer between those runs and added complexity of the bookkeeping seems unnesessary here (it can always be improved later, though, never say never). The most interesting problem here is how to calculate the number of chunks falling into each memory page in the bucket. Skipping all the details, there are three cases when the number of chunks per page is constant: 1) P >= C, P % C == 0 --> N = P / C 2) C > P , C % P == 0 --> N = 1 3) C <= P, P % C != 0 && C % (P % C) == 0 --> N = P / C + 1 where P is page size, C is chunk size and N is the number of chunks per page and the rest of the cases, where the number of chunks per page is calculated on the go, during the page counter array iteration. Among the rest, there are still cases where N can be deduced from the page index, but they require not that much less calculations per page than the current "brute force" way and 2/3 of the buckets fall into the first three categories anyway, so, for the sake of simplicity, it was decided to stick to those two variations. It can always be refined and improved later, should we see that brute force way slows us down unacceptably. Reviewers: eugenis, cryptoad, dvyukov Subscribers: kubamracek, mehdi_amini, llvm-commits Differential Revision: https://reviews.llvm.org/D38245 llvm-svn: 314311
* [sanitizer] Re-introduce kUseSeparateSizeClassForBatch for the 32-bit PrimaryKostya Kortchinsky2017-08-281-0/+17
| | | | | | | | | | | | | | | | | | | | | | | Summary: Currently `TransferBatch` are located within the same memory regions as "regular" chunks. This is not ideal for security: they make for an interesting target to overwrite, and are not protected by the frontend (namely, Scudo). To solve this, we re-introduce `kUseSeparateSizeClassForBatch` for the 32-bit Primary allowing for `TransferBatch` to end up in their own memory region. Currently only Scudo would use this new feature, the default behavior remains unchanged. The separate `kBatchClassID` was used for a brief period of time previously but removed when the 64-bit ended up using the "free array". Reviewers: alekseyshl, kcc, eugenis Reviewed By: alekseyshl Subscribers: llvm-commits, kubamracek Differential Revision: https://reviews.llvm.org/D37082 llvm-svn: 311891
* [sanitizers CMake] NFC Refactor the logic for compiling and generating testsGeorge Karpenkov2017-08-151-34/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | into a function. Most CMake configuration under compiler-rt/lib/*/tests have almost-the-same-but-not-quite functions of the form add_X_[unit]tests for compiling and running the tests. Much of the logic is duplicated with minor variations across different sub-folders. This can harm productivity for multiple reasons: For newcomers, resulting CMake files are very large, hard to understand, and hide the intention of the code. Changes for enabling certain architectures end up being unnecessarily large, as they get duplicated across multiple folders. Adding new sub-projects requires more effort than it should, as a developer has to again copy-n-paste the configuration, and it's not even clear from which sub-project it should be copy-n-pasted. With this change the logic of compile-and-generate-a-set-of-tests is extracted into a function, which hopefully makes writing and reading CMake much easier. Differential Revision: https://reviews.llvm.org/D36116 llvm-svn: 310971
* [sanitizers] Add a blocking boolean to GetRandom prototypeKostya Kortchinsky2017-08-141-9/+11
| | | | | | | | | | | | | | | | | | | | | | Summary: On platforms with `getrandom`, the system call defaults to blocking. This becomes an issue in the very early stage of the boot for Scudo, when the RNG source is not set-up yet: the syscall will block and we'll stall. Introduce a parameter to specify that the function should not block, defaulting to blocking as the underlying syscall does. Update Scudo to use the non-blocking version. Reviewers: alekseyshl Reviewed By: alekseyshl Subscribers: llvm-commits, kubamracek Differential Revision: https://reviews.llvm.org/D36399 llvm-svn: 310839
* Add NetBSD support in sanitizer_test_utils.hKamil Rytarowski2017-08-071-3/+3
| | | | | | | | | | | | | | | | | | | | | | Summary: NetBSD ships with printf_l(3) like FreeBSD. NetBSD does not ship with memalign, pvalloc, malloc with "usable size" and is the same here as Darwin, Android, FreeBSD and Windows. Sponsored by <The NetBSD Foundation> Reviewers: joerg, vitalybuka, kcc, fjricci, filcab Reviewed By: vitalybuka Subscribers: srhines, llvm-commits, emaste, kubamracek, #sanitizers Tags: #sanitizers Differential Revision: https://reviews.llvm.org/D36373 llvm-svn: 310248
* [sanitizers] Sanitizer tests CMake clean up: try #2George Karpenkov2017-07-281-15/+2
| | | | | | | | | | | | | | | | | This patch addresses two issues: Most of the time, hacks with `if/else` in order to get support for multi-configuration builds are superfluous. The variable `CMAKE_CFG_INTDIR` was created precisely for this purpose: it expands to `.` on all single-configuration builds, and to a configuration name otherwise. The `if/else` hacks for the library name generation should also not be done, as CMake has `TARGET_FILE` generator expression precisely for this purpose, as it expands to the exact filename of the resulting target. Differential Revision: https://reviews.llvm.org/D35952 llvm-svn: 309341
* Revert "[sanitizers] Sanitizer tests CMake clean up"George Karpenkov2017-07-271-2/+15
| | | | | | | | This reverts commit 0ab44db2aa1cd3710355ad79b04f954ce68c0b3a. Fails on some bots, reverting until I can fix it. llvm-svn: 309318
* [sanitizers] Sanitizer tests CMake clean upGeorge Karpenkov2017-07-271-15/+2
| | | | | | | | | | | | | | | | | This patch addresses two issues: Most of the time, hacks with `if/else` in order to get support for multi-configuration builds are superfluous. The variable `CMAKE_CFG_INTDIR` was created precisely for this purpose: it expands to `.` on all single-configuration builds, and to a configuration name otherwise. The `if/else` hacks for the library name generation should also not be done, as CMake has `TARGET_FILE` generator expression precisely for this purpose, as it expands to the exact filename of the resulting target. Differential Revision: https://reviews.llvm.org/D35952 llvm-svn: 309306
* [sanitizer_common] Move filesystem-related code out of sanitizer_common.ccVitaly Buka2017-07-223-0/+3
| | | | | | | | | | | | | | | | | | | | | | Summary: This is a pure refactoring change. It just moves code that is related to filesystem operations from sanitizer_common.{cc,h} to sanitizer_file.{cc,h}. This makes it cleaner to disable the filesystem-related code for a new port that doesn't want it. Submitted on behalf of Roland McGrath. Reviewers: kcc, eugenis, alekseyshl Reviewed By: alekseyshl Subscribers: vitalybuka, llvm-commits, kubamracek, mgorny, phosek Tags: #sanitizers Differential Revision: https://reviews.llvm.org/D35591 llvm-svn: 308819
* Revert "[sanitizer_common] Move filesystem-related code out of ↵Vitaly Buka2017-07-203-3/+0
| | | | | | | | | | sanitizer_common.cc" Breaks Windows build. This reverts commit r308640. llvm-svn: 308648
* [sanitizer_common] Move filesystem-related code out of sanitizer_common.ccAlex Shlyapnikov2017-07-203-0/+3
| | | | | | | | | | | | | | | | | This is a pure refactoring change. It just moves code that is related to filesystem operations from sanitizer_common.{cc,h} to sanitizer_file.{cc,h}. This makes it cleaner to disable the filesystem-related code for a new port that doesn't want it. Commiting for mcgrathr. Reviewers: alekseyshl Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D35591 llvm-svn: 308640
* [compiler-rt] Fix fix format specifies type in testVitaly Buka2017-07-161-2/+2
| | | | llvm-svn: 308117
* [Sanitizers] 64 bit allocator respects allocator_may_return_null flagAlex Shlyapnikov2017-06-261-16/+18
| | | | | | | | | | | | | | | | Summary: Make SizeClassAllocator64 return nullptr when it encounters OOM, which allows the entire sanitizer's allocator to follow allocator_may_return_null=1 policy (LargeMmapAllocator: D34243, SizeClassAllocator64: D34433). Reviewers: eugenis Subscribers: srhines, kubamracek, llvm-commits Differential Revision: https://reviews.llvm.org/D34540 llvm-svn: 306342
* [Sanitizers] 32 bit allocator respects allocator_may_return_null flagAlex Shlyapnikov2017-06-221-2/+2
| | | | | | | | | | | | | | | | | | | Summary: Make SizeClassAllocator32 return nullptr when it encounters OOM, which allows the entire sanitizer's allocator to follow allocator_may_return_null=1 policy, even for small allocations (LargeMmapAllocator is already fixed by D34243). Will add a test for OOM in primary allocator later, when SizeClassAllocator64 can gracefully handle OOM too. Reviewers: eugenis Subscribers: kubamracek, llvm-commits Differential Revision: https://reviews.llvm.org/D34433 llvm-svn: 305972
OpenPOWER on IntegriCloud