summaryrefslogtreecommitdiff
path: root/test/msan/chained_origin_limits.cc
AgeCommit message (Collapse)Author
2016-12-08[MSAN][MIPS] Fix fork.cc test on MIPSSagar Thakur
Summary: For platforms which support slow unwinder only, we restrict the store context size to 1, basically only storing the current pc. We do this because the slow unwinder which is based on libunwind is not async signal safe and causes random freezes in forking applications as well as in signal handlers. Reviewed by eugenis. Differential: D23107 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@289027 91177308-0d34-0410-b5e6-96231b3b80d8
2016-08-18[mips][msan] Fix all the XPASSes following r278793 and r278795Daniel Sanders
All msan tests are now passing for mipsel and mips64el except for allocator_mapping.cc which is marked unsupported. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@279048 91177308-0d34-0410-b5e6-96231b3b80d8
2016-08-15[mips] XFAIL mips64el tests that fail on clang-cmake-mipselDaniel Sanders
These tests were recently enabled and have never worked on this builder. Three tests were sensitive to line number changes: test/msan/Linux/obstack.cc test/msan/chained_origin.cc test/msan/chained_origin_memcpy.cc and this sensitivity will be addressed in a follow-up patch. Of these, obstack.cc's sensitivity to line numbers is unexplained since it already uses [[@LINE]]. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@278671 91177308-0d34-0410-b5e6-96231b3b80d8
2015-10-29[compiler-rt] [msan] Unify aarch64 mappingAdhemerval Zanella
This patch unify the 39-bit and 42-bit mapping for aarch64 to use only one instrumentation algorithm. A runtime check avoid mapping 42-bit only segments for 39-bit kernels. The mapping to use now is for 39 and 42-bits: 0x00000000000ULL-0x01000000000ULL MappingDesc::INVALID 0x01000000000ULL-0x02000000000ULL MappingDesc::SHADOW 0x02000000000ULL-0x03000000000ULL MappingDesc::ORIGIN 0x03000000000ULL-0x04000000000ULL MappingDesc::SHADOW 0x04000000000ULL-0x05000000000ULL MappingDesc::ORIGIN 0x05000000000ULL-0x06000000000ULL MappingDesc::APP 0x06000000000ULL-0x07000000000ULL MappingDesc::INVALID 0x07000000000ULL-0x08000000000ULL MappingDesc::APP And only for 42-bits: 0x08000000000ULL-0x09000000000ULL MappingDesc::INVALID 0x09000000000ULL-0x0A000000000ULL MappingDesc::SHADOW 0x0A000000000ULL-0x0B000000000ULL MappingDesc::ORIGIN 0x0B000000000ULL-0x0F000000000ULL MappingDesc::INVALID 0x0F000000000ULL-0x10000000000ULL MappingDesc::APP 0x10000000000ULL-0x11000000000ULL MappingDesc::INVALID 0x11000000000ULL-0x12000000000ULL MappingDesc::APP 0x12000000000ULL-0x17000000000ULL MappingDesc::INVALID 0x17000000000ULL-0x18000000000ULL MappingDesc::SHADOW 0x18000000000ULL-0x19000000000ULL MappingDesc::ORIGIN 0x19000000000ULL-0x20000000000ULL MappingDesc::INVALID 0x20000000000ULL-0x21000000000ULL MappingDesc::APP 0x21000000000ULL-0x26000000000ULL MappingDesc::INVALID 0x26000000000ULL-0x27000000000ULL MappingDesc::SHADOW 0x27000000000ULL-0x28000000000ULL MappingDesc::ORIGIN 0x28000000000ULL-0x29000000000ULL MappingDesc::SHADOW 0x29000000000ULL-0x2A000000000ULL MappingDesc::ORIGIN 0x2A000000000ULL-0x2B000000000ULL MappingDesc::APP 0x2B000000000ULL-0x2C000000000ULL MappingDesc::INVALID 0x2C000000000ULL-0x2D000000000ULL MappingDesc::SHADOW 0x2D000000000ULL-0x2E000000000ULL MappingDesc::ORIGIN 0x2E000000000ULL-0x2F000000000ULL MappingDesc::APP 0x2F000000000ULL-0x39000000000ULL MappingDesc::INVALID 0x39000000000ULL-0x3A000000000ULL MappingDesc::SHADOW 0x3A000000000ULL-0x3B000000000ULL MappingDesc::ORIGIN 0x3B000000000ULL-0x3C000000000ULL MappingDesc::APP 0x3C000000000ULL-0x3D000000000ULL MappingDesc::INVALID 0x3D000000000ULL-0x3E000000000ULL MappingDesc::SHADOW 0x3E000000000ULL-0x3F000000000ULL MappingDesc::ORIGIN 0x3F000000000ULL-0x40000000000ULL MappingDesc::APP And although complex it provides a better memory utilization that previous one. [1] http://reviews.llvm.org/D13817 git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@251625 91177308-0d34-0410-b5e6-96231b3b80d8
2015-09-16[MSan] Enable MSAN for aarch64Adhemerval Zanella
This patch enabled msan for aarch64 with 39-bit VMA and 42-bit VMA. As defined by lib/msan/msan.h the memory layout used is for 39-bit is: 00 0000 0000 - 40 0000 0000: invalid 40 0000 0000 - 43 0000 0000: shadow 43 0000 0000 - 46 0000 0000: origin 46 0000 0000 - 55 0000 0000: invalid 55 0000 0000 - 56 0000 0000: app (low) 56 0000 0000 - 70 0000 0000: invalid 70 0000 0000 - 80 0000 0000: app (high) And for 42-bit VMA: 000 0000 0000 - 100 0000 0000: invalid 100 0000 0000 - 11b 0000 0000: shadow 11b 0000 0000 - 120 0000 0000: invalid 120 0000 0000 - 13b 0000 0000: origin 13b 0000 0000 - 2aa 0000 0000: invalid 2aa 0000 0000 - 2ab 0000 0000: app (low) 2ab 0000 0000 - 3f0 0000 0000: invalid 3f0 0000 0000 - 400 0000 0000: app (high) Most of tests are passing with exception of: * Linux/mallinfo.cc * chained_origin_limits.cc * dlerror.cc * param_tls_limit.cc * signal_stress_test.cc * nonnull-arg.cpp The 'Linux/mallinfo.cc' is due the fact AArch64 returns the sret in 'x8' instead of default first argument 'x1'. So a function prototype that aims to mimic (by using first argument as the return of function) won't work. For GCC one can make a register alias (register var asm ("r8")), but for clang it detects is an unused variable and generate wrong code. The 'chained_origin_limits' is probably due a wrong code generation, since it fails only when origin memory is used (-fsanitize-memory-track-origins=2) and only in the returned code (return buf[50]). The 'signal_streess_test' and 'nonnull-arg' are due currently missing variadic argument handling in memory sanitizer code instrumentation on LLVM side. Both 'dlerror' and 'param_tls_test' are unknown failures that require further investigation. All the failures are XFAIL for aarch64 for now. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@247809 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-02[MSan] Remove explicit -m64 from RUN lines.Alexey Samsonov
Target-specific flags should usually be configured by CMake/lit. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@230999 91177308-0d34-0410-b5e6-96231b3b80d8
2014-09-08[msan] Make chained_origin_limits test faster.Evgeniy Stepanov
git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@217361 91177308-0d34-0410-b5e6-96231b3b80d8
2014-09-03[msan] Fix origin_history_per_stack_limit=0 behavior.Evgeniy Stepanov
It disables the per-stack limit. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@217030 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-30[msan] Limit stack origin chain length.Evgeniy Stepanov
Stack origins were created with unlimited length by mistake. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@212036 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-25[msan] Fix bad interaction between with-calls mode and chained origin tracking.Evgeniy Stepanov
Origin history should only be recorded for uninitialized values, because it is meaningless otherwise. This change moves __msan_chain_origin to the runtime library side and makes it conditional on the corresponding shadow value. Previous code was correct, but _very_ inefficient. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@211700 91177308-0d34-0410-b5e6-96231b3b80d8
2014-05-21[msan] Chained origins re-design.Evgeniy Stepanov
Generalize StackDepot and create a new specialized instance of it to efficiently (i.e. without duplicating stack trace data) store the origin history tree. This reduces memory usage for chained origins roughly by an order of magnitude. Most importantly, this new design allows us to put two limits on stored history data (exposed in MSAN_OPTIONS) that help avoid exponential growth in used memory on certain workloads. See comments in lib/msan/msan_origin.h for more details. git-svn-id: https://llvm.org/svn/llvm-project/compiler-rt/trunk@209284 91177308-0d34-0410-b5e6-96231b3b80d8
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-22 07:06:38 +0000