summaryrefslogtreecommitdiffstats
path: root/compiler-rt
Commit message (Collapse)AuthorAgeFilesLines
* [XRay][compiler-rt] Support string-based config for Basic mode.Dean Michael Berris2018-05-048-28/+191
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This addresses http://llvm.org/PR36790. This change allows the XRay Basic Mode implementation to use the string-based initialization routine provided through `__xray_log_init_mode(...)`. In the process, we've also deprecated some flags defined for the `XRAY_OPTIONS` environment variable. We then introduce another environment variable that can control the XRay Basic Mode implementation through `XRAY_BASIC_OPTIONS`. We also rename files from `xray_inmemory_log` to `xray_basic_logging` to be more in line with the mode implementation. Depends on D46174. Reviewers: echristo, kpw, pelikan, eizan Reviewed By: kpw Subscribers: mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D46246 llvm-svn: 331507
* [XRay][compiler-rt] Support string-based config for FDR modeDean Michael Berris2018-05-049-59/+208
| | | | | | | | | | | | | | | | | | | | | | | | Summary: In this chage we add support for the string-based configuration mechanism for configuring FDR mode. We deprecate most of the `xray_fdr_log_*` flags that are set with the `XRAY_OPTIONS` environment variable. Instead we make the FDR implementation take defaults from the `XRAY_FDR_OPTIONS` environment variable, and use the flags defined in `xray_fdr_flags.{h,cc,inc}` for the options we support. This change addresses http://llvm.org/PR36790. Depends on D46173. Reviewers: eizan, pelikan, kpw, echristo Subscribers: llvm-commits, mgorny Differential Revision: https://reviews.llvm.org/D46174 llvm-svn: 331506
* [XRay][compiler-rt+docs] Introduce __xray_log_init_mode(...).Dean Michael Berris2018-05-043-31/+121
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This addresses http://llvm.org/PR36790. The change Deprecates a number of functions and types in `include/xray/xray_log_interface.h` to recommend using string-based configuration of XRay through the __xray_log_init_mode(...) function. In particular, this deprecates the following: - `__xray_set_log_impl(...)` -- users should instead use the `__xray_log_register_mode(...)` and `__xray_log_select_mode(...)` APIs. - `__xray_log_init(...)` -- users should instead use the `__xray_log_init_mode(...)` function, which also requires using the `__xray_log_register_mode(...)` and `__xray_log_select_mode(...)` functionality. - `__xray::FDRLoggingOptions` -- in following patches, we'll be migrating the FDR logging implementations (and tests) to use the string-based configuration. In later stages we'll remove the `__xray::FDRLoggingOptions` type, and ask users to migrate to using the string-based configuration mechanism instead. - `__xray::BasicLoggingOptions` -- same as `__xray::FDRLoggingOptions`, we'll be removing this type later and instead rely exclusively on the string-based configuration API. We also update the documentation to reflect the new advice and remove some of the deprecated notes. Reviewers: eizan, kpw, echristo, pelikan Reviewed By: kpw Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D46173 llvm-svn: 331503
* Revert "Follow-up to r331378. Update tests to allow to use C atomics in C++."Volodymyr Sapsai2018-05-033-3/+3
| | | | | | | | | | | | | It reverts commit r331484 because it caused test failures ThreadSanitizer-x86_64 :: Darwin/gcd-groups-destructor.mm ThreadSanitizer-x86_64 :: Darwin/libcxx-shared-ptr-stress.mm ThreadSanitizer-x86_64 :: Darwin/xpc-race.mm Foundation.h transitively includes <atomic>, so we have a case of benign mixing <stdatomic.h> and <atomic>. llvm-svn: 331491
* Follow-up to r331378. Update tests to allow to use C atomics in C++.Volodymyr Sapsai2018-05-033-3/+3
| | | | | | | | | | | | Reviewers: kubamracek Reviewed By: kubamracek Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D46363 llvm-svn: 331484
* [sanitizer] Remove unused 32-bit allocator TransferBatch parameterKostya Kortchinsky2018-05-032-3/+2
| | | | | | | | | | | | | | | | | Summary: NFC. Remove an unused parameter in `SizeClassAllocator32::TransferBatch::SetFromArray`, and thus get rid of the compilation warning. Reviewers: alekseyshl, vitalybuka Reviewed By: vitalybuka Subscribers: kubamracek, delcypher, #sanitizers, llvm-commits Differential Revision: https://reviews.llvm.org/D46397 llvm-svn: 331477
* [sanitizer] Fix Fuchsia ReadBinaryName not to crash when uninitializedPetr Hosek2018-05-021-2/+4
| | | | | | | | | | | | | If the sanitizer runtime is loaded in a binary that doesn't really support it, then __sanitizer_startup_hook will never have been called to initialize StoredArgv. This case can't be supported, but its failure mode shouldn't be to crash in sanitizer_common internals. Patch By: mcgrathr Differential Revision: https://reviews.llvm.org/D46344 llvm-svn: 331382
* [libFuzzer] Don't short-circuit from CrashCallback.Matt Morehouse2018-05-021-3/+2
| | | | | | | | Short-circuiting causes tests to fail on Mac since libFuzzer crashes rather than exiting with an error code when an unexpected signal happens. llvm-svn: 331324
* [libFuzzer] Report at most one crash per input.Matt Morehouse2018-05-019-0/+57
| | | | | | | | | | | | | | | | | | Summary: Fixes https://github.com/google/sanitizers/issues/788/, a deadlock caused by multiple crashes happening at the same time. Before printing a crash report, we now test and set an atomic flag. If the flag was already set, the crash handler returns immediately. Reviewers: kcc Reviewed By: kcc Subscribers: llvm-commits, kubamracek Differential Revision: https://reviews.llvm.org/D46277 llvm-svn: 331310
* [compiler-rt][X86][AMD][Bulldozer] Fix Bulldozer Model 2 detection.Roman Lebedev2018-05-011-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The compiler-rt side of D46314 I have discovered an issue by accident. ``` $ lscpu Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 8 On-line CPU(s) list: 0-7 Thread(s) per core: 2 Core(s) per socket: 4 Socket(s): 1 NUMA node(s): 1 Vendor ID: AuthenticAMD CPU family: 21 Model: 2 Model name: AMD FX(tm)-8350 Eight-Core Processor Stepping: 0 CPU MHz: 3584.018 CPU max MHz: 4000.0000 CPU min MHz: 1400.0000 BogoMIPS: 8027.22 Virtualization: AMD-V L1d cache: 16K L1i cache: 64K L2 cache: 2048K L3 cache: 8192K NUMA node0 CPU(s): 0-7 Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 popcnt aes xsave avx f16c lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 tce nodeid_msr tbm topoext perfctr_core perfctr_nb cpb hw_pstate vmmcall bmi1 arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold ``` So this is model-2 bulldozer AMD CPU. GCC agrees: ``` $ echo | gcc -E - -march=native -### <...> /usr/lib/gcc/x86_64-linux-gnu/7/cc1 -E -quiet -imultiarch x86_64-linux-gnu - "-march=bdver2" -mmmx -mno-3dnow -msse -msse2 -msse3 -mssse3 -msse4a -mcx16 -msahf -mno-movbe -maes -mno-sha -mpclmul -mpopcnt -mabm -mlwp -mfma -mfma4 -mxop -mbmi -mno-sgx -mno-bmi2 -mtbm -mavx -mno-avx2 -msse4.2 -msse4.1 -mlzcnt -mno-rtm -mno-hle -mno-rdrnd -mf16c -mno-fsgsbase -mno-rdseed -mprfchw -mno-adx -mfxsr -mxsave -mno-xsaveopt -mno-avx512f -mno-avx512er -mno-avx512cd -mno-avx512pf -mno-prefetchwt1 -mno-clflushopt -mno-xsavec -mno-xsaves -mno-avx512dq -mno-avx512bw -mno-avx512vl -mno-avx512ifma -mno-avx512vbmi -mno-avx5124fmaps -mno-avx5124vnniw -mno-clwb -mno-mwaitx -mno-clzero -mno-pku -mno-rdpid --param "l1-cache-size=16" --param "l1-cache-line-size=64" --param "l2-cache-size=2048" "-mtune=bdver2" <...> ``` But clang does not: (look for `bdver1`) ``` $ echo | clang -E - -march=native -### clang version 7.0.0- (trunk) Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/local/bin "/usr/lib/llvm-7/bin/clang" "-cc1" "-triple" "x86_64-pc-linux-gnu" "-E" "-disable-free" "-disable-llvm-verifier" "-discard-value-names" "-main-file-name" "-" "-mrelocation-model" "static" "-mthread-model" "posix" "-mdisable-fp-elim" "-fmath-errno" "-masm-verbose" "-mconstructor-aliases" "-munwind-tables" "-fuse-init-array" "-target-cpu" "bdver1" "-target-feature" "+sse2" "-target-feature" "+cx16" "-target-feature" "+sahf" "-target-feature" "+tbm" "-target-feature" "-avx512ifma" "-target-feature" "-sha" "-target-feature" "-gfni" "-target-feature" "+fma4" "-target-feature" "-vpclmulqdq" "-target-feature" "+prfchw" "-target-feature" "-bmi2" "-target-feature" "-cldemote" "-target-feature" "-fsgsbase" "-target-feature" "-xsavec" "-target-feature" "+popcnt" "-target-feature" "+aes" "-target-feature" "-avx512bitalg" "-target-feature" "-xsaves" "-target-feature" "-avx512er" "-target-feature" "-avx512vnni" "-target-feature" "-avx512vpopcntdq" "-target-feature" "-clwb" "-target-feature" "-avx512f" "-target-feature" "-clzero" "-target-feature" "-pku" "-target-feature" "+mmx" "-target-feature" "+lwp" "-target-feature" "-rdpid" "-target-feature" "+xop" "-target-feature" "-rdseed" "-target-feature" "-waitpkg" "-target-feature" "-ibt" "-target-feature" "+sse4a" "-target-feature" "-avx512bw" "-target-feature" "-clflushopt" "-target-feature" "+xsave" "-target-feature" "-avx512vbmi2" "-target-feature" "-avx512vl" "-target-feature" "-avx512cd" "-target-feature" "+avx" "-target-feature" "-vaes" "-target-feature" "-rtm" "-target-feature" "+fma" "-target-feature" "+bmi" "-target-feature" "-rdrnd" "-target-feature" "-mwaitx" "-target-feature" "+sse4.1" "-target-feature" "+sse4.2" "-target-feature" "-avx2" "-target-feature" "-wbnoinvd" "-target-feature" "+sse" "-target-feature" "+lzcnt" "-target-feature" "+pclmul" "-target-feature" "-prefetchwt1" "-target-feature" "+f16c" "-target-feature" "+ssse3" "-target-feature" "-sgx" "-target-feature" "-shstk" "-target-feature" "+cmov" "-target-feature" "-avx512vbmi" "-target-feature" "-movbe" "-target-feature" "-xsaveopt" "-target-feature" "-avx512dq" "-target-feature" "-adx" "-target-feature" "-avx512pf" "-target-feature" "+sse3" "-dwarf-column-info" "-debugger-tuning=gdb" "-resource-dir" "/usr/lib/llvm-7/lib/clang/7.0.0" "-internal-isystem" "/usr/local/include" "-internal-isystem" "/usr/lib/llvm-7/lib/clang/7.0.0/include" "-internal-externc-isystem" "/usr/include/x86_64-linux-gnu" "-internal-externc-isystem" "/include" "-internal-externc-isystem" "/usr/include" "-fdebug-compilation-dir" "/build/llvm-build-Clang-release" "-ferror-limit" "19" "-fmessage-length" "271" "-fobjc-runtime=gcc" "-fdiagnostics-show-option" "-fcolor-diagnostics" "-o" "-" "-x" "c" "-" ``` So clang, unlike gcc, considers this to be `bdver1`. After some digging, i've come across `getAMDProcessorTypeAndSubtype()` in `Host.cpp`. I have added the following debug printf after the call to that function in `sys::getHostCPUName()`: ``` errs() << "Family " << Family << " Model " << Model << " Type " << Type "\n"; ``` Which produced: ``` Family 21 Model 2 Type 5 ``` Which matches the `lscpu` output. As it was pointed in the review by @craig.topper: >>! In D46314#1084123, @craig.topper wrote: > I dont' think this is right. Here is what I found on wikipedia. https://en.wikipedia.org/wiki/List_of_AMD_CPU_microarchitectures. > > AMD Bulldozer Family 15h - the successor of 10h/K10. Bulldozer is designed for processors in the 10 to 220W category, implementing XOP, FMA4 and CVT16 instruction sets. Orochi was the first design which implemented it. For Bulldozer, CPUID model numbers are 00h and 01h. > AMD Piledriver Family 15h (2nd-gen) - successor to Bulldozer. CPUID model numbers are 02h (earliest "Vishera" Piledrivers) and 10h-1Fh. > AMD Steamroller Family 15h (3rd-gen) - third-generation Bulldozer derived core. CPUID model numbers are 30h-3Fh. > AMD Excavator Family 15h (4th-gen) - fourth-generation Bulldozer derived core. CPUID model numbers are 60h-6Fh, later updated revisions have model numbers 70h-7Fh. > > > So there's a weird exception where model 2 should go with 0x10-0x1f. Though It does not help that the code can't be tested at the moment. With this logical change, the `bdver2` is properly detected. ``` $ echo | /build/llvm-build-Clang-release/bin/clang -E - -march=native -### clang version 7.0.0 (trunk 331249) (llvm/trunk 331256) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /build/llvm-build-Clang-release/bin "/build/llvm-build-Clang-release/bin/clang-7" "-cc1" "-triple" "x86_64-unknown-linux-gnu" "-E" "-disable-free" "-main-file-name" "-" "-mrelocation-model" "static" "-mthread-model" "posix" "-mdisable-fp-elim" "-fmath-errno" "-masm-verbose" "-mconstructor-aliases" "-munwind-tables" "-fuse-init-array" "-target-cpu" "bdver2" "-target-feature" "+sse2" "-target-feature" "+cx16" "-target-feature" "+sahf" "-target-feature" "+tbm" "-target-feature" "-avx512ifma" "-target-feature" "-sha" "-target-feature" "-gfni" "-target-feature" "+fma4" "-target-feature" "-vpclmulqdq" "-target-feature" "+prfchw" "-target-feature" "-bmi2" "-target-feature" "-cldemote" "-target-feature" "-fsgsbase" "-target-feature" "-xsavec" "-target-feature" "+popcnt" "-target-feature" "+aes" "-target-feature" "-avx512bitalg" "-target-feature" "-movdiri" "-target-feature" "-xsaves" "-target-feature" "-avx512er" "-target-feature" "-avx512vnni" "-target-feature" "-avx512vpopcntdq" "-target-feature" "-clwb" "-target-feature" "-avx512f" "-target-feature" "-clzero" "-target-feature" "-pku" "-target-feature" "+mmx" "-target-feature" "+lwp" "-target-feature" "-rdpid" "-target-feature" "+xop" "-target-feature" "-rdseed" "-target-feature" "-waitpkg" "-target-feature" "-movdir64b" "-target-feature" "-ibt" "-target-feature" "+sse4a" "-target-feature" "-avx512bw" "-target-feature" "-clflushopt" "-target-feature" "+xsave" "-target-feature" "-avx512vbmi2" "-target-feature" "-avx512vl" "-target-feature" "-avx512cd" "-target-feature" "+avx" "-target-feature" "-vaes" "-target-feature" "-rtm" "-target-feature" "+fma" "-target-feature" "+bmi" "-target-feature" "-rdrnd" "-target-feature" "-mwaitx" "-target-feature" "+sse4.1" "-target-feature" "+sse4.2" "-target-feature" "-avx2" "-target-feature" "-wbnoinvd" "-target-feature" "+sse" "-target-feature" "+lzcnt" "-target-feature" "+pclmul" "-target-feature" "-prefetchwt1" "-target-feature" "+f16c" "-target-feature" "+ssse3" "-target-feature" "-sgx" "-target-feature" "-shstk" "-target-feature" "+cmov" "-target-feature" "-avx512vbmi" "-target-feature" "-movbe" "-target-feature" "-xsaveopt" "-target-feature" "-avx512dq" "-target-feature" "-adx" "-target-feature" "-avx512pf" "-target-feature" "+sse3" "-dwarf-column-info" "-debugger-tuning=gdb" "-resource-dir" "/build/llvm-build-Clang-release/lib/clang/7.0.0" "-internal-isystem" "/usr/local/include" "-internal-isystem" "/build/llvm-build-Clang-release/lib/clang/7.0.0/include" "-internal-externc-isystem" "/usr/include/x86_64-linux-gnu" "-internal-externc-isystem" "/include" "-internal-externc-isystem" "/usr/include" "-fdebug-compilation-dir" "/build/llvm-build-Clang-release" "-ferror-limit" "19" "-fmessage-length" "271" "-fobjc-runtime=gcc" "-fdiagnostics-show-option" "-fcolor-diagnostics" "-o" "-" "-x" "c" "-" ``` Reviewers: craig.topper, asbirlea, rnk, GGanesh, andreadb Reviewed By: craig.topper Subscribers: sdardis, dberris, aprantl, arichardson, JDevlieghere, #sanitizers, llvm-commits, cfe-commits, craig.topper Differential Revision: https://reviews.llvm.org/D46323 llvm-svn: 331295
* tsan: disable trace switching after multithreaded forkDmitry Vyukov2018-04-302-0/+6
| | | | | | | | | | | | The problem is reported in: https://github.com/google/sanitizers/issues/945 We already disable as much as possible after multithreaded fork, trace switching is last place that can hang due to basic operations (memory accesses, function calls). Disable it too. llvm-svn: 331163
* [XRay][profiler] Part 1: XRay Allocator and Array ImplementationsDean Michael Berris2018-04-296-16/+711
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This change is part of the larger XRay Profiling Mode effort. Here we implement an arena allocator, for fixed sized buffers used in a segmented array implementation. This change adds the segmented array data structure, which relies on the allocator to provide and maintain the storage for the segmented array. Key features of the `Allocator` type: * It uses cache-aligned blocks, intended to host the actual data. These blocks are cache-line-size multiples of contiguous bytes. * The `Allocator` has a maximum memory budget, set at construction time. This allows us to cap the amount of data each specific `Allocator` instance is responsible for. * Upon destruction, the `Allocator` will clean up the storage it's used, handing it back to the internal allocator used in sanitizer_common. Key features of the `Array` type: * Each segmented array is always backed by an `Allocator`, which is either user-provided or uses a global allocator. * When an `Array` grows, it grows by appending a segment that's fixed-sized. The size of each segment is computed by the number of elements of type `T` that can fit into cache line multiples. * An `Array` does not return memory to the `Allocator`, but it can keep track of the current number of "live" objects it stores. * When an `Array` is destroyed, it will not return memory to the `Allocator`. Users should clean up the `Allocator` independently of the `Array`. * The `Array` type keeps a freelist of the chunks it's used before, so that trimming and growing will re-use previously allocated chunks. These basic data structures are used by the XRay Profiling Mode implementation to implement efficient and cache-aware storage for data that's typically read-and-write heavy for tracking latency information. We're relying on the cache line characteristics of the architecture to provide us good data isolation and cache friendliness, when we're performing operations like searching for elements and/or updating data hosted in these cache lines. Reviewers: echristo, pelikan, kpw Subscribers: mgorny, llvm-commits Differential Revision: https://reviews.llvm.org/D45756 llvm-svn: 331141
* tsan: improve "destroy of a locked mutex" reportsDmitry Vyukov2018-04-274-2/+52
| | | | | | | | | | | | | | | 1. Allow to suppress by current stack. We generally allow to suppress by all main stacks. Current is probably the stack one wants to use to suppress such reports. 2. Fix last lock stack restoration. We trimmed shadow value by storing it in u32. This magically worked for the test that provoked the report on the main thread. But this breaks for locks in any other threads. llvm-svn: 331023
* Revert "[CMake] Make simple source used for CMake checks a C file"Petr Hosek2018-04-271-1/+1
| | | | | | | This reverts commit r331003 which breaks sanitizer bots because of missing 32-bit libstdc++ library. llvm-svn: 331009
* [CMake] Make simple source used for CMake checks a C filePetr Hosek2018-04-261-1/+1
| | | | | | | | | | | The source being compiled is plain C, but using .cc extension forces it to be compiled as C++ which requires a working C++ compiler including C++ library which may not be the case when we're building compiler-rt together with libcxx as part of runtimes build. Differential Revision: https://reviews.llvm.org/D46152 llvm-svn: 331003
* [asan] Align __asan_global_start so that it works with LLDReid Kleckner2018-04-262-2/+20
| | | | | | | | | | | Otherwise LLD will not align the .ASAN$GA section start, and &__asan_globals + 1 will not be the start of the next real ASan global metadata in .ASAN$GL. We discovered this issue when attempting to use LLD on Windows in Chromium: https://crbug.com/837090 llvm-svn: 330990
* Enable full debug info in the ASan runtime on WindowsReid Kleckner2018-04-261-5/+5
| | | | | | | | Clang-cl supports the -gline-tables-only flag, so we were going down that path. Honestly, we should just go ahead and enable full codeview support. llvm-svn: 330989
* Add s390x to XFAIL for illegal_read/write_test.ccPetar Jovanovic2018-04-252-2/+2
| | | | | | | | | Follow up to r330840 and r330849. It seems that s390 is also not distinguishing illegal WRITE and READ memory access. Add s390x to XFAIL for the tests. llvm-svn: 330863
* [scudo] Adding an interface function to print allocator statsKostya Kortchinsky2018-04-255-0/+43
| | | | | | | | | | | | | | | | Summary: This adds `__scudo_print_stats` as an interface function to display the Primary and Secondary allocator statistics for Scudo. Reviewers: alekseyshl, flowerhack Reviewed By: alekseyshl Subscribers: delcypher, llvm-commits, #sanitizers Differential Revision: https://reviews.llvm.org/D46016 llvm-svn: 330857
* Finetune supported arches for the tests added in r330840Petar Jovanovic2018-04-252-0/+2
| | | | | | | r330840 introduced two tests that may not be supported on all architectures. powerpc64 seems to be one of those. llvm-svn: 330849
* [mips] Implement GetWriteFlag() for mipsPetar Jovanovic2018-04-253-0/+76
| | | | | | | | | | | | | The read/write flag is set by manually decoding the instruction that caused the exception. It is implemented this way because the cause register which contains the needed flag was removed from the signal context structure which the user handler receives from the kernel. Patch by Milos Stojanovic. Differential Revision: https://reviews.llvm.org/D45768 llvm-svn: 330840
* Remove 'noexcept's that do not match between header and source file.Richard Smith2018-04-241-3/+3
| | | | | | This code is ill-formed, but under -fno-exceptions compilers generally accept it (at least, prior to C++17). This allows this code to be built by Clang in C++17 mode. llvm-svn: 330765
* [sanitizer] More dead code removalKostya Kortchinsky2018-04-243-49/+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
* The OpenBSD UBsan port introduced two typos that broke the Solaris sanitizer ↵Rainer Orth2018-04-242-2/+2
| | | | | | | | | | build. The following patch restores it, will shortly commit as obvious. Differential Revision: https://reviews.llvm.org/D46006 llvm-svn: 330712
* [LibFuzzer] Tweak `MutationDispatcher::Mutate_CopyPart` mutation.Dan Liew2018-04-242-1/+18
| | | | | | | | | | | | It doesn't make sense to non-deterministically choose between `CopyPart(..)` and `InsertPart(..)` when it is known that `InsertPart(..)` will fail. This upstream's a change from JFS solver's fork of LibFuzzer. Differential Revision: https://reviews.llvm.org/D45693 llvm-svn: 330687
* [HWASan] Use dynamic shadow memory on Android only.Alex Shlyapnikov2018-04-241-3/+3
| | | | | | | | There're issues with IFUNC support on other platforms. Differential Revision: https://reviews.llvm.org/D45847 llvm-svn: 330666
* [libFuzzer] Add feature to not use AFL's deferred forkserver.Matt Morehouse2018-04-231-1/+13
| | | | | | | | | | | | | | A small but substantial minority of libFuzzer-based fuzzers run code that does not play well with fork in global constructors or LLVMFuzzerInitialize. This patch allows these fuzzers to use afl_driver by allowing them to opt-out of using AFL's deferred forkserver which deferres calling fork until after this code. Patch By: metzman Differential Revision: https://reviews.llvm.org/D45744 llvm-svn: 330652
* Change kAllocatorSpace for powerpc64.Martin Liska2018-04-231-1/+1
| | | | | | | | Fixes issue: https://github.com/google/sanitizers/issues/933 Differential Revision: https://reviews.llvm.org/D45950 llvm-svn: 330650
* [Sanitizer] Internal Printf string width + left-justify.Alex Shlyapnikov2018-04-232-11/+35
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* [HWASan] Add files missing in r330624Alex Shlyapnikov2018-04-233-0/+244
| | | | llvm-svn: 330628
* [HWASan] Introduce non-zero based and dynamic shadow memory (compiler-rt).Alex Shlyapnikov2018-04-2310-70/+169
| | | | | | | | | | | | | | | Retire the fixed shadow memory mapping to avoid conflicts with default process memory mapping (currently manifests on Android). Tests on AArch64 show <1% performance loss and code size increase, making it possible to use dynamic shadow memory by default. Keep the fixed shadow memory mapping around to be able to run performance comparison tests later. Re-commiting D45847 with fixed shadow for x86-64. llvm-svn: 330624
* Revert r330474 - "[HWASan] Introduce non-zero based and dynamic shadow ↵Reid Kleckner2018-04-2313-409/+70
| | | | | | | | | | | | | | | memory (compiler-rt)." This commit causes internal errors with ld.bfd 2.24. My guess is that the ifunc usage in this commit is causing problems. This is the default system linker on Trusty Tahr, which is from 2014. I claim it's still in our support window. Maybe we will decide to drop support for it, but let's get the bots green while we do the investigation and have that discussion. Discovered here: https://crbug.com/835864 llvm-svn: 330619
* Fix clang-cl warnings in compiler-rtReid Kleckner2018-04-233-4/+5
| | | | | | | | | 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
* [scudo] Read ARM feature bits using Fuchsia APIs.Kostya Kortchinsky2018-04-231-1/+12
| | | | | | | | | | | | | | | | | Summary: Fuchsia uses zx_system_get_features in lieu of getauxval. Use this call when checking for CRC32 support. Reviewers: cryptoad Reviewed By: cryptoad Subscribers: delcypher, llvm-commits, #sanitizers, kristof.beyls, chrib Differential Revision: https://reviews.llvm.org/D45896 llvm-svn: 330598
* Revert "[Sanitizer] Internal Printf string precision argument + padding."Alex Shlyapnikov2018-04-202-9/+2
| | | | | | | | | This reverts commit r330458. There are existing code using string precision as 'max len', need more work. llvm-svn: 330476
* [HWASan] Introduce non-zero based and dynamic shadow memory (compiler-rt).Alex Shlyapnikov2018-04-2013-70/+409
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: Retire the fixed shadow memory mapping to avoid conflicts with default process memory mapping (currently manifests on Android). Tests on AArch64 show <1% performance loss and code size increase, making it possible to use dynamic shadow memory by default. For the simplicity and unifirmity sake, use dynamic shadow memory mapping with base address accessed via ifunc resolver on all supported platforms. Keep the fixed shadow memory mapping around to be able to run performance comparison tests later. Complementing D45840. Reviewers: eugenis Subscribers: srhines, kubamracek, dberris, mgorny, kristof.beyls, delcypher, #sanitizers, llvm-commits Differential Revision: https://reviews.llvm.org/D45847 llvm-svn: 330474
* asan: Mark printf-4.c as unsupported on Windows.Peter Collingbourne2018-04-201-2/+3
| | | | | | | | | Although sprintf is not intercepted on Windows, this test can pass if sprintf calls memmove, which is intercepted, so we can't XFAIL it. Differential Revision: https://reviews.llvm.org/D45894 llvm-svn: 330469
* [Sanitizer] Internal Printf string precision argument + padding.Alex Shlyapnikov2018-04-202-2/+9
| | | | | | | | | | | | | | | | | | | | | | 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
* Revert r330376 "[sanitizer] Generalize atomic_uint8_t, atomic_uint16_t, ... ↵Hans Wennborg2018-04-201-10/+28
| | | | | | | | | | into a template. NFC." This broke the Windows build, see e.g. http://lab.llvm.org:8011/builders/clang-x64-ninja-win7/builds/10130 > Differential Revision: https://reviews.llvm.org/D44246 llvm-svn: 330395
* [LibFuzzer] Report when custom counters are available.Dan Liew2018-04-202-0/+4
| | | | | | | | This upstreams a feature from the JFS solver's fork of LibFuzzer. Differential Revision: https://reviews.llvm.org/D45675 llvm-svn: 330391
* [LibFuzzer] Try to unbreak the `FuzzerMutate.ShuffleBytes1` unit test.Dan Liew2018-04-201-1/+1
| | | | | | | | | | | | | | This test is failing on my Linux box. Just increasing the number of iterations works around this. The divergence is likely due to our reliance on `std::shuffle()` which is not guaranteed to have the same behaviour across platforms. This is a strong argument for us to implement our own shuffle function to avoid divergence in behaviour across platforms. Differential Revision: https://reviews.llvm.org/D45767 llvm-svn: 330390
* [LibFuzzer] Unbreak the `trace-malloc-unbalanced.test` when using Python 3.Dan Liew2018-04-201-5/+5
| | | | | | | | | The `unbalanced_allocs.py` script uses Python 2 print statement and `iteritems()`. Running `2to3` over the script fixes these. Differential Revision: https://reviews.llvm.org/D45765 llvm-svn: 330389
* [Fuzzer] Add a missing header in Fuchsia implementationPetr Hosek2018-04-201-0/+1
| | | | | | | | This is needed for fd_set. Differential Revision: https://reviews.llvm.org/D45852 llvm-svn: 330383
* [sanitizer] Generalize atomic_uint8_t, atomic_uint16_t, ... into a template. ↵Kuba Mracek2018-04-191-28/+10
| | | | | | | | NFC. Differential Revision: https://reviews.llvm.org/D44246 llvm-svn: 330376
* [sanitizer] Minor refactor of some ReservedAddressRange functionsKostya Kortchinsky2018-04-193-37/+20
| | | | | | | | | | | | | | | | | | | 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
* [Fuzzer] Make InterruptHandler non-blocking for FuchsiaPetr Hosek2018-04-191-1/+6
| | | | | | | | | | | | | The initial naive approach to simulate SIGINT on Fuchsia was to getchar and look for ETX. This caused the InterruptHandler thread to lock stdin, preventing musl's exit() from being able to close the stdio descriptors and complete. This change uses select() instead. Patch By: aarongreen Differential Revision: https://reviews.llvm.org/D45636 llvm-svn: 330328
* tsan: fix compiler warningsDmitry Vyukov2018-04-191-3/+3
| | | | | | vmaSize is uptr, so we need to print it with %zd. llvm-svn: 330312
* [HWASan] Add "N" suffix to generic __hwasan_load/store.Alex Shlyapnikov2018-04-183-8/+30
| | | | | | | | | | | | | | | Summary: "N" suffix is added by the instrumentation and interface functions are expected to be exported from the library as __hwasan_loadN* and __hwasan_storeN*. Reviewers: eugenis Subscribers: kubamracek, delcypher, #sanitizers, llvm-commits Differential Revision: https://reviews.llvm.org/D45739 llvm-svn: 330297
* [sanitizer] Minor refactor of ThreadDescriptorSizeKostya Kortchinsky2018-04-181-14/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: While I was sifting through dead code findings, I stumbled on this function. First, for `__s390__` it always returned 0 for the 1st call, which doesn't seem right. 2nd call & beyond would return the correct value though. Then it duplicated the `atomic_store` multiple times, sometimes with a `if`, sometimes without. Finally it used a capitalized variable name starting with `k` which indicates a constant, and it is not. So: - rename the static global variable; - change the atomic functions to their relaxed version; - move the store to the end, and make sure we return `val` all the time. Reviewers: alekseyshl, eugenis, koriakin Reviewed By: alekseyshl Subscribers: kubamracek, delcypher, llvm-commits, #sanitizers Differential Revision: https://reviews.llvm.org/D45725 llvm-svn: 330268
* [XRay][compiler-rt] Add noop patch functions for unsupported arches.Keith Wyss2018-04-175-0/+30
| | | | | | | | | | | | | | Summary: Typed event patching is implemented for x86-64, but functions must be defined for other arches. Reviewers: dberris, pelikan Subscribers: nemanjai, javed.absar, delcypher, #sanitizers, llvm-commits Differential Revision: https://reviews.llvm.org/D45749 llvm-svn: 330231
OpenPOWER on IntegriCloud