search for: sancov

I'll need more details then. Maybe you can share the binary & its .sancov file? Or if you have a way to reproduce it? On Tue, Mar 7, 2017 at 1:23 PM Kostya Serebryany <kcc at google.com> wrote: > On Tue, Mar 7, 2017 at 12:50 PM, Mike Aizatsky <aizatsky at google.com> > wrote: > > Justin, > > I haven't seen this before. I suspect it is...

Rafael, Filipe, I am looking at the fixes you apply to sanitizer tests and they worry me. (e.g. https://reviews.llvm.org/D31498) The fixes are mostly mechanical and thus every single change looks safe, but given the amount of changes there is large risk to cripple some of the tests in a way that they will stop detecting failures. When I write a test for new functionality, I always verify that

...://llvm.org/viewvc/llvm-project?rev=261524&view=rev > Log: > Fix some abuse of auto flagged by clang's -Wrange-loop-analysis. > > Modified: > llvm/trunk/lib/Target/PowerPC/PPCBoolRetToInt.cpp > llvm/trunk/lib/Transforms/Utils/MemorySSA.cpp > llvm/trunk/tools/sancov/sancov.cc > > Modified: llvm/trunk/lib/Target/PowerPC/PPCBoolRetToInt.cpp > URL: > http://llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/PowerPC/PPCBoolRetToInt.cpp?rev=261524&r1=261523&r2=261524&view=diff > ============================================================...

...ine]] int inline_bar2() { int x = inline_foo(); if (x % 37) { x += 3; } return x; } }; int Foo::public_foo() { return inline_foo() ? inline_bar1() : inline_bar2(); } ``` Compiling this with `clang++ -fsanitize-coverage=trace-pc-guard /tmp/test.cpp -c -O1` generates sancov guards (__sancov_gen_.X) that are used outside of their comdat group due to inlining: ``` @__sancov_gen_.1 = private global [3 x i32] zeroinitializer, section "__sancov_guards", comdat($_ZN3Foo10inline_fooEv) define dso_local i32 @_ZN3Foo10public_fooEv(%struct.Foo* %0) local_unnamed_ad...

...I wanted to take a look at how my coverage was doing, as per the instructions here: http://llvm.org/docs/LibFuzzer.html#how-good-is-my-fuzzer First of all, I suspect the instructions there are out of date, but passing -dump_coverage=1 to the binary rather than setting ASAN_OPTIONS generated a .sancov file for me. However, when I inspect this with the sancov tool, all of the line numbers it reports are "<invalid>:0". I can list the covered and uncovered functions successfully, but without locations it's really hard to do anything with that information. I've built with -...

...how my coverage was doing, as per the instructions here: > > http://llvm.org/docs/LibFuzzer.html#how-good-is-my-fuzzer > > First of all, I suspect the instructions there are out of date, but > passing -dump_coverage=1 to the binary rather than setting ASAN_OPTIONS > generated a .sancov file for me. > > However, when I inspect this with the sancov tool, all of the line > numbers it reports are "<invalid>:0". I can list the covered and > uncovered functions successfully, but without locations it's really hard > to do anything with that information...

Is there is minimum required version for GCC to build LLVM from the head revision? I have GCC v4.9.3, but 'Tools/sancov/sancov.cc' won't build because 'std::to_string' does not exist. When running CMake it did not flag GCC v4.9.3 as too old, and it is passing the '-std=gnu++11' option, but apparently this version of GCC is not fully C++ 11 compliant, or at least its C++ library isn't....

...t; > > > >So there is significant potential here. However, we have not explored > these > >ideas any further, and we would highly appreciate any feedback about their > >viability and potential added value in comparison to what is already > >available in llvm-cov and sancov. (feedback needed) > > > >To conclude, we introduced bcov [1] and discussed a few areas where the > >LLVM community can help us assess its potential, identify related work, > and > >plan its future direction. Many thanks in advance for your feedback. > > > > &...

...n)); SecEnd->setVisibility(GlobalValue::HiddenVisibility); + appendToUsed(M, {SecStart, SecEnd}); return std::make_pair(SecStart, SecEnd); } I'm trying it out now. Kostya Serebryany <kcc at google.com> writes: > With -Wl,-gc-sections I get this: > SimpleTest.cpp:(.text.sancov.module_ctor[sancov.module_ctor]+0x1b): > undefined reference to `__start___sancov_pcs' > SimpleTest.cpp:(.text.sancov.module_ctor[sancov.module_ctor]+0x20): > undefined reference to `__stop___sancov_pcs' > > > > On Thu, Aug 24, 2017 at 3:07 PM, George Karpenkov <ekar...

> On Aug 24, 2017, at 2:55 PM, Kostya Serebryany <kcc at google.com> wrote: > > Interesting. > This is a relatively new addition (fsanitize-coverage=pc-tables, which is now a part of -fsanitize=fuzzer). > The tests worked (did they? On Mac?) so I thought everything is ok. For tests we never compile the tested target with -O3 (and that wouldn’t be sufficient), and for

...F targets llvm.used has no effect on the object file (only on the optimizer). Is there a simple way to reproduce the link failure? Peter > >> >> Kostya Serebryany <kcc at google.com> writes: >> > With -Wl,-gc-sections I get this: >> > SimpleTest.cpp:(.text.sancov.module_ctor[sancov.module_ctor]+0x1b): >> > undefined reference to `__start___sancov_pcs' >> > SimpleTest.cpp:(.text.sancov.module_ctor[sancov.module_ctor]+0x20): >> > undefined reference to `__stop___sancov_pcs' >> > >> > >> > >>...

...db 100644 --- a/compiler-rt/lib/fuzzer/FuzzerMain.cpp +++ b/compiler-rt/lib/fuzzer/FuzzerMain.cpp @@ -16,6 +16,10 @@ extern "C" { int LLVMFuzzerTestOneInput(const uint8_t *Data, size_t Size); } // extern "C" +__attribute__((weak)) void nop(void *p) {} +extern void *__start___sancov_pcs; + int main(int argc, char **argv) { + nop(__start___sancov_pcs); return fuzzer::FuzzerDriver(&argc, &argv, LLVMFuzzerTestOneInput); } The problem also goes away if I use "GNU ld (GNU Binutils) 2.28.51.20170105". Peter > > > > > >> >> Pete...

.../compiler-rt/lib/fuzzer/FuzzerMain.cpp > > @@ -16,6 +16,10 @@ extern "C" { > > int LLVMFuzzerTestOneInput(const uint8_t *Data, size_t Size); > > } // extern "C" > > > > +__attribute__((weak)) void nop(void *p) {} > > +extern void *__start___sancov_pcs; > > + > > int main(int argc, char **argv) { > > + nop(__start___sancov_pcs); > > return fuzzer::FuzzerDriver(&argc, &argv, LLVMFuzzerTestOneInput); > > } > > If we were to do this, we'd have to guard it appropriately - not all > platform...

...gt; > @@ -16,6 +16,10 @@ extern "C" { >>> > int LLVMFuzzerTestOneInput(const uint8_t *Data, size_t Size); >>> > } // extern "C" >>> > >>> > +__attribute__((weak)) void nop(void *p) {} >>> > +extern void *__start___sancov_pcs; >>> > + >>> > int main(int argc, char **argv) { >>> > + nop(__start___sancov_pcs); >>> > return fuzzer::FuzzerDriver(&argc, &argv, LLVMFuzzerTestOneInput); >>> > } >>> >>> If we were to do this, we'...

...I'm playing around with LLVM and stumbled upon this issue while while performing "make install". The build itself was successful. I'm using the latest git version. #make install -- Installing: /home/alesko/llvm-install/bin/llvm-mc -- Installing: /home/alesko/llvm-install/bin/sancov -- Installing: /home/alesko/llvm-install/bin/opt -- Installing: /home/alesko/llvm-install/bin/llvm-split -- Installing: /home/alesko/llvm-install/bin/llvm-cov -- Installing: /home/alesko/llvm-install/bin/obj2yaml CMake Error at docs/cmake_install.cmake:36 (file): file INSTALL cannot find &quo...

...of basic blocks). This can be useful for profiling. So there is significant potential here. However, we have not explored these ideas any further, and we would highly appreciate any feedback about their viability and potential added value in comparison to what is already available in llvm-cov and sancov. (feedback needed) To conclude, we introduced bcov [1] and discussed a few areas where the LLVM community can help us assess its potential, identify related work, and plan its future direction. Many thanks in advance for your feedback. Kind regards, Ammar [1]: https://github.com/abenkhadra/b...

...bled upon this issue while while performing "make install". The build itself was successful. I'm using the latest git version. >> >> #make install >> >> -- Installing: /home/alesko/llvm-install/bin/llvm-mc >> -- Installing: /home/alesko/llvm-install/bin/sancov >> -- Installing: /home/alesko/llvm-install/bin/opt >> -- Installing: /home/alesko/llvm-install/bin/llvm-split >> -- Installing: /home/alesko/llvm-install/bin/llvm-cov >> -- Installing: /home/alesko/llvm-install/bin/obj2yaml >> CMake Error at docs/cmake_install.cmake:3...

...espace 464M tool-template 464M clang-rename 462M clang-reorder-fields 460M find-all-symbols 456M clang-doc 452M clang-include-fixer 444M modularize 443M clang-func-mapping 442M clang-diff 441M libToolingExample00 438M pp-trace 434M diagtool 184M llvm-cfi-verify 170M llvm-objdump 168M sancov 158M llvm-rtdyld 149M llvm-ar 148M llvm-nm 145M llvm-extract 145M llvm-link 142M llvm-dwarfdump 141M llvm-split 131M llvm-mc 127M llvm-pdbutil 126M clang-offload-bundler 122M llvm-mca 121M verify-uselistorder 121M llvm-cat 120M llvm-as 117M llvm-special-case-list-fuzzer 117M llvm-de...

...mum required version for GCC to build LLVM from the > head revision? Last I checked it was 4.7. The CMake files also tell me that's correct: modules/CheckCompilerVersion.cmake: # Check if the host compiler is new enough. LLVM requires at least GCC 4.7, > I have GCC v4.9.3, but ‘Tools/sancov/sancov.cc’ won’t build because > ‘std::to_string’ does not exist. When running CMake it did not flag > GCC > v4.9.3 as too old, and it is passing the ‘-std=gnu++11’ option, but > apparently this version of GCC is not fully C++ 11 compliant, or at > least its C++ library isn’t....

I believe a good amount of them (if not most of them) have already been ported! Off the top of my head, I remember that asan, tsan, msan, hwasan, the kernel santizers, and sancov have been ported. I don't think ubsan has been ported yet though. You can also check if other passes you need run under the new PM by checking PassRegistry.def. On Fri, Aug 2, 2019, 14:20 Jordan Rupprecht <rupprecht at google.com> wrote: > Hi Leonard, > Is the new pass manager ex...