summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Transforms/Instrumentation/SanitizerCoverage.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Sink all InitializePasses.h includesReid Kleckner2019-11-131-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This file lists every pass in LLVM, and is included by Pass.h, which is very popular. Every time we add, remove, or rename a pass in LLVM, it caused lots of recompilation. I found this fact by looking at this table, which is sorted by the number of times a file was changed over the last 100,000 git commits multiplied by the number of object files that depend on it in the current checkout: recompiles touches affected_files header 342380 95 3604 llvm/include/llvm/ADT/STLExtras.h 314730 234 1345 llvm/include/llvm/InitializePasses.h 307036 118 2602 llvm/include/llvm/ADT/APInt.h 213049 59 3611 llvm/include/llvm/Support/MathExtras.h 170422 47 3626 llvm/include/llvm/Support/Compiler.h 162225 45 3605 llvm/include/llvm/ADT/Optional.h 158319 63 2513 llvm/include/llvm/ADT/Triple.h 140322 39 3598 llvm/include/llvm/ADT/StringRef.h 137647 59 2333 llvm/include/llvm/Support/Error.h 131619 73 1803 llvm/include/llvm/Support/FileSystem.h Before this change, touching InitializePasses.h would cause 1345 files to recompile. After this change, touching it only causes 550 compiles in an incremental rebuild. Reviewers: bkramer, asbirlea, bollu, jdoerfert Differential Revision: https://reviews.llvm.org/D70211
* [Alignment][NFC] Remove dependency on GlobalObject::setAlignment(unsigned)Guillaume Chatelet2019-10-151-2/+3
| | | | | | | | | | | | | | | | | Summary: This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet Subscribers: arsenm, mehdi_amini, jvesely, nhaehnle, hiraditya, steven_wu, dexonsmith, dang, llvm-commits Tags: #llvm Differential Revision: https://reviews.llvm.org/D68944 llvm-svn: 374880
* [NewPM][Sancov] Make Sancov a Module Pass instead of 2 PassesLeonard Chan2019-09-041-227/+129
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch merges the sancov module and funciton passes into one module pass. The reason for this is because we ran into an out of memory error when attempting to run asan fuzzer on some protobufs (pc.cc files). I traced the OOM error to the destructor of SanitizerCoverage where we only call appendTo[Compiler]Used which calls appendToUsedList. I'm not sure where precisely in appendToUsedList causes the OOM, but I am able to confirm that it's calling this function *repeatedly* that causes the OOM. (I hacked sancov a bit such that I can still create and destroy a new sancov on every function run, but only call appendToUsedList after all functions in the module have finished. This passes, but when I make it such that appendToUsedList is called on every sancov destruction, we hit OOM.) I don't think the OOM is from just adding to the SmallSet and SmallVector inside appendToUsedList since in either case for a given module, they'll have the same max size. I suspect that when the existing llvm.compiler.used global is erased, the memory behind it isn't freed. I could be wrong on this though. This patch works around the OOM issue by just calling appendToUsedList at the end of every module run instead of function run. The same amount of constants still get added to llvm.compiler.used, abd we make the pass usage and logic simpler by not having any inter-pass dependencies. Differential Revision: https://reviews.llvm.org/D66988 llvm-svn: 370971
* [Sanitizer] Remove unused functionsAlexandre Ganea2019-08-201-9/+0
| | | | | | Differential Revision: https://reviews.llvm.org/D66503 llvm-svn: 369468
* Reland the "[NewPM] Port Sancov" patch from rL365838. No functionalLeonard Chan2019-07-251-109/+257
| | | | | | | | | | | | | | | | | | | | | changes were made to the patch since then. -------- [NewPM] Port Sancov This patch contains a port of SanitizerCoverage to the new pass manager. This one's a bit hefty. Changes: - Split SanitizerCoverageModule into 2 SanitizerCoverage for passing over functions and ModuleSanitizerCoverage for passing over modules. - ModuleSanitizerCoverage exists for adding 2 module level calls to initialization functions but only if there's a function that was instrumented by sancov. - Added legacy and new PM wrapper classes that own instances of the 2 new classes. - Update llvm tests and add clang tests. llvm-svn: 367053
* Added address-space mangling for stack related intrinsicsChristudasan Devadasan2019-07-221-2/+4
| | | | | | | | | | | | Modified the following 3 intrinsics: int_addressofreturnaddress, int_frameaddress & int_sponentry. Reviewed By: arsenm Differential Revision: https://reviews.llvm.org/D64561 llvm-svn: 366679
* Revert "[NewPM] Port Sancov"Leonard Chan2019-07-151-243/+116
| | | | | | This reverts commit 5652f35817f07b16f8b3856d594cc42f4d7ee29c. llvm-svn: 366153
* Remove unused methods in Sancov.Leonard Chan2019-07-121-27/+6
| | | | llvm-svn: 365931
* [NewPM] Port SancovLeonard Chan2019-07-111-109/+257
| | | | | | | | | | | | | | | | | This patch contains a port of SanitizerCoverage to the new pass manager. This one's a bit hefty. Changes: - Split SanitizerCoverageModule into 2 SanitizerCoverage for passing over functions and ModuleSanitizerCoverage for passing over modules. - ModuleSanitizerCoverage exists for adding 2 module level calls to initialization functions but only if there's a function that was instrumented by sancov. - Added legacy and new PM wrapper classes that own instances of the 2 new classes. - Update llvm tests and add clang tests. Differential Revision: https://reviews.llvm.org/D62888 llvm-svn: 365838
* [SanitizerCoverage] Use different module ctor names for trace-pc-guard and ↵Fangrui Song2019-05-071-8/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | inline-8bit-counters Fixes the main issue in PR41693 When both modes are used, two functions are created: `sancov.module_ctor`, `sancov.module_ctor.$LastUnique`, where $LastUnique is the current LastUnique counter that may be different in another module. `sancov.module_ctor.$LastUnique` belongs to the comdat group of the same name (due to the non-null third field of the ctor in llvm.global_ctors). COMDAT group section [ 9] `.group' [sancov.module_ctor] contains 6 sections: [Index] Name [ 10] .text.sancov.module_ctor [ 11] .rela.text.sancov.module_ctor [ 12] .text.sancov.module_ctor.6 [ 13] .rela.text.sancov.module_ctor.6 [ 23] .init_array.2 [ 24] .rela.init_array.2 # 2 problems: # 1) If sancov.module_ctor in this module is discarded, this group # has a relocation to a discarded section. ld.bfd and gold will # error. (Another issue: it is silently accepted by lld) # 2) The comdat group has an unstable name that may be different in # another translation unit. Even if the linker allows the dangling relocation # (with --noinhibit-exec), there will be many undesired .init_array entries COMDAT group section [ 25] `.group' [sancov.module_ctor.6] contains 2 sections: [Index] Name [ 26] .init_array.2 [ 27] .rela.init_array.2 By using different module ctor names, the associated comdat group names will also be different and thus stable across modules. Reviewed By: morehouse, phosek Differential Revision: https://reviews.llvm.org/D61510 llvm-svn: 360107
* [SanitizerCoverage] Avoid splitting critical edges when destination is a ↵Craig Topper2019-03-121-1/+1
| | | | | | | | | | | | basic block containing unreachable This patch adds a new option to SplitAllCriticalEdges and uses it to avoid splitting critical edges when the destination basic block ends with unreachable. Otherwise if we split the critical edge, sanitizer coverage will instrument the new block that gets inserted for the split. But since this block itself shouldn't be reachable this is pointless. These basic blocks will stick around and generate assembly, but they don't end in sane control flow and might get placed at the end of the function. This makes it look like one function has code that flows into the next function. This showed up while compiling the linux kernel with clang. The kernel has a tool called objtool that detected the code that appeared to flow from one function to the next. https://github.com/ClangBuiltLinux/linux/issues/351#issuecomment-461698884 Differential Revision: https://reviews.llvm.org/D57982 llvm-svn: 355947
* [sancov] Instrument reachable blocks that end in unreachableReid Kleckner2019-02-281-3/+3
| | | | | | | | | | | | | | | | | | Summary: These sorts of blocks often contain calls to noreturn functions, like longjmp, throw, or trap. If they don't end the program, they are "interesting" from the perspective of sanitizer coverage, so we should instrument them. This was discussed in https://reviews.llvm.org/D57982. Reviewers: kcc, vitalybuka Subscribers: llvm-commits, craig.topper, efriedma, morehouse, hiraditya Tags: #llvm Differential Revision: https://reviews.llvm.org/D58740 llvm-svn: 355152
* [SanitizerCoverage] Clang crashes if user declares `__sancov_lowest_stack` ↵Julian Lettner2019-02-041-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | variable Summary: If the user declares or defines `__sancov_lowest_stack` with an unexpected type, then `getOrInsertGlobal` inserts a bitcast and the following cast fails: ``` Constant *SanCovLowestStackConstant = M.getOrInsertGlobal(SanCovLowestStackName, IntptrTy); SanCovLowestStack = cast<GlobalVariable>(SanCovLowestStackConstant); ``` This variable is a SanitizerCoverage implementation detail and the user should generally never have a need to access it, so we emit an error now. rdar://problem/44143130 Reviewers: morehouse Differential Revision: https://reviews.llvm.org/D57633 llvm-svn: 353100
* [opaque pointer types] Pass value type to GetElementPtr creation.James Y Knight2019-02-011-2/+2
| | | | | | | | | This cleans up all GetElementPtr creation in LLVM to explicitly pass a value type rather than deriving it from the pointer's element-type. Differential Revision: https://reviews.llvm.org/D57173 llvm-svn: 352913
* [opaque pointer types] Pass value type to LoadInst creation.James Y Knight2019-02-011-2/+2
| | | | | | | | | This cleans up all LoadInst creation in LLVM to explicitly pass the value type rather than deriving it from the pointer's element-type. Differential Revision: https://reviews.llvm.org/D57172 llvm-svn: 352911
* [opaque pointer types] Add a FunctionCallee wrapper type, and use it.James Y Knight2019-02-011-59/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Recommit r352791 after tweaking DerivedTypes.h slightly, so that gcc doesn't choke on it, hopefully. Original Message: The FunctionCallee type is effectively a {FunctionType*,Value*} pair, and is a useful convenience to enable code to continue passing the result of getOrInsertFunction() through to EmitCall, even once pointer types lose their pointee-type. Then: - update the CallInst/InvokeInst instruction creation functions to take a Callee, - modify getOrInsertFunction to return FunctionCallee, and - update all callers appropriately. One area of particular note is the change to the sanitizer code. Previously, they had been casting the result of `getOrInsertFunction` to a `Function*` via `checkSanitizerInterfaceFunction`, and storing that. That would report an error if someone had already inserted a function declaraction with a mismatching signature. However, in general, LLVM allows for such mismatches, as `getOrInsertFunction` will automatically insert a bitcast if needed. As part of this cleanup, cause the sanitizer code to do the same. (It will call its functions using the expected signature, however they may have been declared.) Finally, in a small number of locations, callers of `getOrInsertFunction` actually were expecting/requiring that a brand new function was being created. In such cases, I've switched them to Function::Create instead. Differential Revision: https://reviews.llvm.org/D57315 llvm-svn: 352827
* [sanitizer-coverage] prune trace-cmp instrumentation for CMP isntructions ↵Kostya Serebryany2019-01-311-2/+34
| | | | | | that feed into the backedge branch. Instrumenting these CMP instructions is almost always useless (and harmful) for fuzzing llvm-svn: 352818
* Revert "[opaque pointer types] Add a FunctionCallee wrapper type, and use it."James Y Knight2019-01-311-51/+59
| | | | | | | | | This reverts commit f47d6b38c7a61d50db4566b02719de05492dcef1 (r352791). Seems to run into compilation failures with GCC (but not clang, where I tested it). Reverting while I investigate. llvm-svn: 352800
* [opaque pointer types] Add a FunctionCallee wrapper type, and use it.James Y Knight2019-01-311-59/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The FunctionCallee type is effectively a {FunctionType*,Value*} pair, and is a useful convenience to enable code to continue passing the result of getOrInsertFunction() through to EmitCall, even once pointer types lose their pointee-type. Then: - update the CallInst/InvokeInst instruction creation functions to take a Callee, - modify getOrInsertFunction to return FunctionCallee, and - update all callers appropriately. One area of particular note is the change to the sanitizer code. Previously, they had been casting the result of `getOrInsertFunction` to a `Function*` via `checkSanitizerInterfaceFunction`, and storing that. That would report an error if someone had already inserted a function declaraction with a mismatching signature. However, in general, LLVM allows for such mismatches, as `getOrInsertFunction` will automatically insert a bitcast if needed. As part of this cleanup, cause the sanitizer code to do the same. (It will call its functions using the expected signature, however they may have been declared.) Finally, in a small number of locations, callers of `getOrInsertFunction` actually were expecting/requiring that a brand new function was being created. In such cases, I've switched them to Function::Create instead. Differential Revision: https://reviews.llvm.org/D57315 llvm-svn: 352791
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* [SanitizerCoverage] Don't create comdat for interposable functions.Matt Morehouse2019-01-151-1/+1
| | | | | | | | | | | | | | | | | | | Summary: Comdat groups override weak symbol behavior, allowing the linker to keep the comdats for weak symbols in favor of comdats for strong symbols. Fixes the issue described in: https://bugs.chromium.org/p/chromium/issues/detail?id=918662 Reviewers: eugenis, pcc, rnk Reviewed By: pcc, rnk Subscribers: smeenai, rnk, bd1976llvm, hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D56516 llvm-svn: 351247
* [SanitizerCoverage][NFC] Use appendToUsed instead of includeJonathan Metzman2019-01-141-16/+7
| | | | | | | | | | | | | | | | | | | Summary: Use appendToUsed instead of include to ensure that SanitizerCoverage's constructors are not stripped. Also, use isOSBinFormatCOFF() to determine if target binary format is COFF. Reviewers: pcc Reviewed By: pcc Subscribers: hiraditya Differential Revision: https://reviews.llvm.org/D56369 llvm-svn: 351118
* [sancov] Put .SCOV* sections into the right comdat groups on COFFReid Kleckner2018-11-081-2/+3
| | | | | | | | | | | | | | | Avoids linker errors about relocations against discarded sections. This was uncovered during the Chromium clang roll here: https://chromium-review.googlesource.com/c/chromium/src/+/1321863#message-717516acfcf829176f6a2f50980f7a4bdd66469a After this change, Chromium's libGLESv2 links successfully for me. Reviewers: metzman, hans, morehouse Differential Revision: https://reviews.llvm.org/D54232 llvm-svn: 346381
* [SanitizerCoverage] Don't duplicate code to get section pointersJonathan Metzman2018-10-161-33/+15
| | | | | | | | | | | | | | | | | Summary: Merge code used to get section start and section end pointers for SanitizerCoverage constructors. This includes code that handles getting the start pointers when targeting MSVC. Reviewers: kcc, morehouse Reviewed By: morehouse Subscribers: kcc, hiraditya Differential Revision: https://reviews.llvm.org/D53211 llvm-svn: 344657
* move GetOrCreateFunctionComdat to Instrumentation.cpp/Instrumentation.hKostya Serebryany2018-10-121-18/+4
| | | | | | | | | | | | | | | | | | Summary: GetOrCreateFunctionComdat is currently used in SanitizerCoverage, where it's defined. I'm planing to use it in HWASAN as well, so moving it into a common location. NFC Reviewers: morehouse Reviewed By: morehouse Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D53218 llvm-svn: 344433
* [SanitizerCoverage] Prevent /OPT:REF from stripping constructorsJonathan Metzman2018-10-121-0/+21
| | | | | | | | | | | | | | | | | | | | | Summary: Linking with the /OPT:REF linker flag when building COFF files causes the linker to strip SanitizerCoverage's constructors. Prevent this by giving the constructors WeakODR linkage and by passing the linker a directive to include sancov.module_ctor. Include a test in compiler-rt to verify libFuzzer can be linked using /OPT:REF Reviewers: morehouse, rnk Reviewed By: morehouse, rnk Subscribers: rnk, morehouse, hiraditya Differential Revision: https://reviews.llvm.org/D52119 llvm-svn: 344391
* [SanitizerCoverage] Make Inline8bit and TracePC counters dead stripping ↵Max Moroz2018-10-121-3/+4
| | | | | | | | | | | | | | | | | | | | resistant. Summary: Otherwise, at least on Mac, the linker eliminates unused symbols which causes libFuzzer to error out due to a mismatch of the sizes of coverage tables. Issue in Chromium: https://bugs.chromium.org/p/chromium/issues/detail?id=892167 Reviewers: morehouse, kcc, george.karpenkov Reviewed By: morehouse Subscribers: kubamracek, llvm-commits Differential Revision: https://reviews.llvm.org/D53113 llvm-svn: 344345
* [SanitizerCoverage] Create comdat for global arrays.Matt Morehouse2018-09-131-14/+25
| | | | | | | | | | | | | | | | | Summary: Place global arrays in comdat sections with their associated functions. This makes sure they are stripped along with the functions they reference, even on the BFD linker. Reviewers: eugenis Reviewed By: eugenis Subscribers: eraman, hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D51902 llvm-svn: 342186
* Revert "[SanitizerCoverage] Create comdat for global arrays."Matt Morehouse2018-09-111-26/+14
| | | | | | | This reverts r341987 since it will cause trouble when there's a module ID collision. llvm-svn: 341995
* [SanitizerCoverage] Create comdat for global arrays.Matt Morehouse2018-09-111-14/+26
| | | | | | | | | | | | | | | | | Summary: Place global arrays in comdat sections with their associated functions. This makes sure they are stripped along with the functions they reference, even on the BFD linker. Reviewers: eugenis Reviewed By: eugenis Subscribers: eraman, hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D51902 llvm-svn: 341987
* Revert "[SanitizerCoverage] Create comdat for global arrays."Matt Morehouse2018-09-111-31/+14
| | | | | | This reverts r341951 due to bot breakage. llvm-svn: 341965
* [SanitizerCoverage] Create comdat for global arrays.Matt Morehouse2018-09-111-14/+31
| | | | | | | | | | | | | | | | | Summary: Place global arrays in comdat sections with their associated functions. This makes sure they are stripped along with the functions they reference, even on the BFD linker. Reviewers: eugenis Reviewed By: eugenis Subscribers: eraman, hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D51902 llvm-svn: 341951
* [libFuzzer] Port to WindowsMatt Morehouse2018-08-301-6/+33
| | | | | | | | | | | | | | | | | | | | Summary: Port libFuzzer to windows-msvc. This patch allows libFuzzer targets to be built and run on Windows, using -fsanitize=fuzzer and/or fsanitize=fuzzer-no-link. It allows these forms of coverage instrumentation to work on Windows as well. It does not fix all issues, such as those with -fsanitize-coverage=stack-depth, which is not usable on Windows as of this patch. It also does not fix any libFuzzer integration tests. Nearly all of them fail to compile, fixing them will come in a later patch, so libFuzzer tests are disabled on Windows until them. Patch By: metzman Reviewers: morehouse, rnk Reviewed By: morehouse, rnk Subscribers: #sanitizers, delcypher, morehouse, kcc, eraman Differential Revision: https://reviews.llvm.org/D51022 llvm-svn: 341082
* Revert "[libFuzzer] Port to Windows"Matt Morehouse2018-08-291-33/+6
| | | | | | This reverts r340949 due to bot breakage again. llvm-svn: 340954
* [libFuzzer] Port to WindowsMatt Morehouse2018-08-291-6/+33
| | | | | | | | | | | | | | | | | | Summary: Port libFuzzer to windows-msvc. This patch allows libFuzzer targets to be built and run on Windows, using -fsanitize=fuzzer and/or fsanitize=fuzzer-no-link. It allows these forms of coverage instrumentation to work on Windows as well. It does not fix all issues, such as those with -fsanitize-coverage=stack-depth, which is not usable on Windows as of this patch. It also does not fix any libFuzzer integration tests. Nearly all of them fail to compile, fixing them will come in a later patch, so libFuzzer tests are disabled on Windows until them. Reviewers: morehouse, rnk Reviewed By: morehouse, rnk Subscribers: #sanitizers, delcypher, morehouse, kcc, eraman Differential Revision: https://reviews.llvm.org/D51022 llvm-svn: 340949
* Revert "[libFuzzer] Port to Windows"Matt Morehouse2018-08-281-23/+6
| | | | | | This reverts commit r340860 due to failing tests. llvm-svn: 340867
* [libFuzzer] Port to WindowsMatt Morehouse2018-08-281-6/+23
| | | | | | | | | | | | | | | | | | | | Summary: Port libFuzzer to windows-msvc. This patch allows libFuzzer targets to be built and run on Windows, using -fsanitize=fuzzer and/or fsanitize=fuzzer-no-link. It allows these forms of coverage instrumentation to work on Windows as well. It does not fix all issues, such as those with -fsanitize-coverage=stack-depth, which is not usable on Windows as of this patch. It also does not fix any libFuzzer integration tests. Nearly all of them fail to compile, fixing them will come in a later patch, so libFuzzer tests are disabled on Windows until them. Patch By: metzman Reviewers: morehouse, rnk Reviewed By: morehouse, rnk Subscribers: morehouse, kcc, eraman Differential Revision: https://reviews.llvm.org/D51022 llvm-svn: 340860
* [SanitizerCoverage] Add associated metadata to PC guards.Matt Morehouse2018-08-141-0/+3
| | | | | | | | | | | | | | | | | | | | | | | Summary: Without this metadata LLD strips unused PC table entries but won't strip unused guards. This metadata also seems to influence the linker to change the ordering in the PC guard section to match that of the PC table section. The libFuzzer runtime library depends on the ordering of the PC table and PC guard sections being the same. This is not generally guaranteed, so we may need to redesign PC tables/guards/counters in the future. Reviewers: eugenis Reviewed By: eugenis Subscribers: kcc, hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D50483 llvm-svn: 339733
* [SanitizerCoverage] Add associated metadata to 8-bit counters.Matt Morehouse2018-07-121-1/+3
| | | | | | | | | | | | | | | | | | | | Summary: This allows counters associated with unused functions to be dead-stripped along with their functions. This approach is the same one we used for PC tables. Fixes an issue where LLD removes an unused PC table but leaves the 8-bit counter. Reviewers: eugenis Reviewed By: eugenis Subscribers: llvm-commits, hiraditya, kcc Differential Revision: https://reviews.llvm.org/D49264 llvm-svn: 336941
* [Instrumentation] Remove unused includeBenjamin Kramer2018-06-251-1/+0
| | | | | | It's also a layering violation. llvm-svn: 335528
* [SanitizerCoverage] Add associated metadata to pc-tables.Matt Morehouse2018-06-151-1/+5
| | | | | | | | | | | | | | | | | | | | Summary: Using associated metadata rather than llvm.used allows linkers to perform dead stripping with -fsanitize-coverage=pc-table. Unfortunately in my local tests, LLD was the only linker that made use of this metadata. Partially addresses https://bugs.llvm.org/show_bug.cgi?id=34636 and fixes https://github.com/google/sanitizers/issues/971. Reviewers: eugenis Reviewed By: eugenis Subscribers: Dor1s, hiraditya, llvm-commits, kcc Differential Revision: https://reviews.llvm.org/D48203 llvm-svn: 334858
* [sanitizer-coverage] don't instrument a function if it's entry block ends ↵Kostya Serebryany2018-05-111-0/+2
| | | | | | with 'unreachable' llvm-svn: 332072
* [Transforms] Change std::sort to llvm::sort in response to r327219Mandeep Singh Grang2018-04-131-5/+5
| | | | | | | | | | | | | | | | | | | | | | 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. Note: This patch is one of a series of patches to replace *all* std::sort to llvm::sort. Refer the comments section in D44363 for a list of all the required patches. Reviewers: kcc, pcc, danielcdh, jmolloy, sanjoy, dberlin, ruiu Reviewed By: ruiu Subscribers: ruiu, llvm-commits Differential Revision: https://reviews.llvm.org/D45142 llvm-svn: 330059
* [sanitizer-coverage] call appendToUsed once per module, not once per ↵Kostya Serebryany2017-09-091-8/+8
| | | | | | function (which is too slow) llvm-svn: 312855
* [SanitizeCoverage] Enable stack-depth coverage for -fsanitize=fuzzerMatt Morehouse2017-08-301-9/+21
| | | | | | | | | | | | | | | | | | Summary: - Don't sanitize __sancov_lowest_stack. - Don't instrument leaf functions. - Add CoverageStackDepth to Fuzzer and FuzzerNoLink. - Only enable on Linux. Reviewers: vitalybuka, kcc, george.karpenkov Reviewed By: kcc Subscribers: kubamracek, cfe-commits, llvm-commits, hiraditya Differential Revision: https://reviews.llvm.org/D37156 llvm-svn: 312185
* Revert "[SanitizeCoverage] Enable stack-depth coverage for -fsanitize=fuzzer"Matt Morehouse2017-08-291-21/+9
| | | | | | This reverts r312026 due to bot breakage. llvm-svn: 312047
* [SanitizeCoverage] Enable stack-depth coverage for -fsanitize=fuzzerMatt Morehouse2017-08-291-9/+21
| | | | | | | | | | | | | | | | | | Summary: - Don't sanitize __sancov_lowest_stack. - Don't instrument leaf functions. - Add CoverageStackDepth to Fuzzer and FuzzerNoLink. - Disable stack depth tracking on Mac. Reviewers: vitalybuka, kcc, george.karpenkov Reviewed By: kcc Subscribers: kubamracek, cfe-commits, llvm-commits, hiraditya Differential Revision: https://reviews.llvm.org/D37156 llvm-svn: 312026
* [sanitizer-coverage] Mark the guard and 8-bit counter arrays as usedJustin Bogner2017-08-291-7/+14
| | | | | | | | | | | | | | In r311742 we marked the PCs array as used so it wouldn't be dead stripped, but left the guard and 8-bit counters arrays alone since these are referenced by the coverage instrumentation. This doesn't quite work if we want the indices of the PCs array to match the other arrays though, since elements can still end up being dead and disappear. Instead, we mark all three of these arrays as used so that they'll be consistent with one another. llvm-svn: 311959
* [sanitizer-coverage] Return the array from CreatePCArray. NFCJustin Bogner2017-08-281-9/+12
| | | | | | | | | | | Be more consistent with CreateFunctionLocalArrayInSection in the API of CreatePCArray, and assign the member variable in the caller like we do for the guard and 8-bit counter arrays. This also tweaks the order of method declarations to match the order of definitions in the file. llvm-svn: 311955
* [sanitizer-coverage] Clean up trailing whitespace. NFCJustin Bogner2017-08-281-6/+6
| | | | llvm-svn: 311954
OpenPOWER on IntegriCloud