summaryrefslogtreecommitdiffstats
path: root/clang/test/CodeGen/asan-globals.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Remove 24 instances of 'REQUIRES: shell'Reid Kleckner2016-10-201-2/+2
| | | | | | | | | | | | | | | | | Tests fall into one of the following categories: - The requirement was unnecessary - Additional quoting was required for backslashes in paths (see "sed -e 's/\\/\\\\/g'") in the sanitizer tests. - OpenMP used 'REQUIRES: shell' as a proxy for the test failing on Windows. Those tests fail there reliably, so use XFAIL instead. I tried not to remove shell requirements that were added to suppress flaky test failures, but if I screwed up, we can add it back as needed. llvm-svn: 284793
* Implement no_sanitize_address for global varsDouglas Katzman2016-10-141-4/+7
| | | | llvm-svn: 284272
* IR: Make metadata typeless in assembly, clang sideDuncan P. N. Exon Smith2014-12-151-18/+18
| | | | | | Match LLVM changes from r224257. llvm-svn: 224259
* [ASan] Improve blacklisting of global variables.Alexey Samsonov2014-10-171-8/+13
| | | | | | | | | | | | | | | | | | | | | | | | | This commit changes the way we blacklist global variables in ASan. Now the global is excluded from instrumentation (either regular bounds checking, or initialization-order checking) if: 1) Global is explicitly blacklisted by its mangled name. This part is left unchanged. 2) SourceLocation of a global is in blacklisted source file. This changes the old behavior, where instead of looking at the SourceLocation of a variable we simply considered llvm::Module identifier. This was wrong, as identifier may not correspond to the file name, and we incorrectly disabled instrumentation for globals coming from #include'd files. 3) Global is blacklisted by type. Now we build the type of a global variable using Clang machinery (QualType::getAsString()), instead of llvm::StructType::getName(). After this commit, the active users of ASan blacklist files may have to revisit them (this is a backwards-incompatible change). llvm-svn: 220097
* [ASan] Use metadata to pass source-level information from Clang to ASan.Alexey Samsonov2014-08-021-12/+8
| | | | | | | | | | | | | | | | | Instead of creating global variables for source locations and global names, just create metadata nodes and strings. They will be transformed into actual globals in the instrumentation pass (if necessary). This approach is more flexible: 1) we don't have to ensure that our custom globals survive all the optimizations 2) if globals are discarded for some reason, we will simply ignore metadata for them and won't have to erase corresponding globals 3) metadata for source locations can be reused for other purposes: e.g. we may attach source location metadata to alloca instructions and provide better descriptions for stack variables in ASan error reports. No functionality change. llvm-svn: 214604
* [ASan] Collect unmangled names of global variables in Clang to print them in ↵Alexey Samsonov2014-07-121-10/+14
| | | | | | | | | | | | | | | | | error reports. Currently ASan instrumentation pass creates a string with global name for each instrumented global (to include global names in the error report). Global name is already mangled at this point, and we may not be able to demangle it at runtime (e.g. there is no __cxa_demangle on Android). Instead, create a string with fully qualified global name in Clang, and pass it to ASan instrumentation pass in llvm.asan.globals metadata. If there is no metadata for some global, ASan will use the original algorithm. This fixes https://code.google.com/p/address-sanitizer/issues/detail?id=264. llvm-svn: 212872
* [Sanitizer] Reduce the usage of sanitizer blacklist in CodeGenModuleAlexey Samsonov2014-07-071-0/+9
| | | | | | | | | | | | | | | | Get rid of cached CodeGenModule::SanOpts, which was used to turn off sanitizer codegen options if current LLVM Module is blacklisted, and use plain LangOpts.Sanitize instead. 1) Some codegen decisions (turning TBAA or writable strings on/off) shouldn't depend on the contents of blacklist. 2) llvm.asan.globals should *always* be created, even if the module is blacklisted - soon Clang's CodeGen where we read sanitizer blacklist files, so we should properly report which globals are blacklisted to the backend. llvm-svn: 212499
* [ASan] Print exact source location of global variables in error reports.Alexey Samsonov2014-07-021-0/+23
See https://code.google.com/p/address-sanitizer/issues/detail?id=299 for the original feature request. Introduce llvm.asan.globals metadata, which Clang (or any other frontend) may use to report extra information about global variables to ASan instrumentation pass in the backend. This metadata replaces llvm.asan.dynamically_initialized_globals that was used to detect init-order bugs. llvm.asan.globals contains the following data for each global: 1) source location (file/line/column info); 2) whether it is dynamically initialized; 3) whether it is blacklisted (shouldn't be instrumented). Source location data is then emitted in the binary and can be picked up by ASan runtime in case it needs to print error report involving some global. For example: 0x... is located 4 bytes to the right of global variable 'C::array' defined in '/path/to/file:17:8' (0x...) of size 40 These source locations are printed even if the binary doesn't have any debug info. This is an ABI-breaking change. ASan initialization is renamed to __asan_init_v4(). Pre-built libraries compiled with older Clang will not work with the fresh runtime. llvm-svn: 212188
OpenPOWER on IntegriCloud