<div dir="ltr">It can be made as aggressive. You need to compile with `-ffunction-sections` `-fdata-sections` and then link with `-Xlinker --gc-sections`. ld64 is more aggressive due to `.subsections_via_symbols` (aka the two compile flags).<br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 24, 2017 at 3:10 PM, Justin Bogner via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Kostya Serebryany <<a href="mailto:kcc@google.com">kcc@google.com</a>> writes:<br>
> Interesting.<br>
> This is a relatively new addition (fsanitize-coverage=pc-tables, which is<br>
> now a part of -fsanitize=fuzzer).<br>
> The tests worked (did they? On Mac?) so I thought everything is ok.<br>
<br>
</span>It looks like the tests were passing, and I *think* I'd tried my fuzzer<br>
since that change was in place. Maybe something about how we're linking<br>
in compiler-rt makes it more obvious to the linker that these symbols<br>
look dead?<br>
<span class=""><br>
> Yea, we need to make sure the pc-tables are not stripped (this is a<br>
> separate section with globals).<br>
> (I still haven't documented pc-tables, will do soon)<br>
><br>
> Do you know what's the analog of Wl,-dead_strip on Linux?<br>
<br>
</span>I think the closest thing is -Wl,--gc-sections but that might be less<br>
aggressive about it than macOS's linker is.<br>
<div class="HOEnZb"><div class="h5"><br>
> On Thu, Aug 24, 2017 at 2:49 PM, Justin Bogner <<a href="mailto:mail@justinbogner.com">mail@justinbogner.com</a>><br>
> wrote:<br>
><br>
>> George Karpenkov <<a href="mailto:ekarpenkov@apple.com">ekarpenkov@apple.com</a>> writes:<br>
>> > OK so with Kuba’s help I’ve found the error: with optimization, dead<br>
>> > stripping of produced libraries is enabled,<br>
>> > which removes coverage instrumentation.<br>
>> ><br>
>> > However, this has nothing to do with the move to compiler-rt, so I’m<br>
>> > quite skeptical on whether it has worked<br>
>> > beforehand.<br>
>> ><br>
>> > A trivial fix is to do:<br>
>> ><br>
>> > diff --git a/cmake/modules/<wbr>HandleLLVMOptions.cmake b/cmake/modules/<br>
>> HandleLLVMOptions.cmake<br>
>> > index 04596a6ff63..5465d8d95ba 100644<br>
>> > --- a/cmake/modules/<wbr>HandleLLVMOptions.cmake<br>
>> > +++ b/cmake/modules/<wbr>HandleLLVMOptions.cmake<br>
>> > @@ -665,6 +665,9 @@ if(LLVM_USE_SANITIZER)<br>
>> > endif()<br>
>> > if (LLVM_USE_SANITIZE_COVERAGE)<br>
>> > append("-fsanitize=fuzzer-no-<wbr>link" CMAKE_C_FLAGS CMAKE_CXX_FLAGS)<br>
>> > +<br>
>> > + # Dead stripping messes up coverage instrumentation.<br>
>> > + set(LLVM_NO_DEAD_STRIP ON)<br>
>> > endif()<br>
>> > endif()<br>
>> ><br>
>> > Any arguments against that?<br>
>><br>
>> We shouldn't do this. We really only want to prevent dead stripping of<br>
>> the counters themselves - disabling it completely isn't very nice.<br>
>><br>
>> > Apparently, a better way is to follow ASAN instrumentation pass,<br>
>> > which uses some magic to protect against dead-stripping.<br>
>><br>
>> I thought this was already being done - how else did it work before?<br>
>><br>
>> >> On Aug 24, 2017, at 11:29 AM, Justin Bogner <<a href="mailto:mail@justinbogner.com">mail@justinbogner.com</a>><br>
>> wrote:<br>
>> >><br>
>> >> (kcc, george: sorry for the re-send, the first was from a non-list email<br>
>> >> address)<br>
>> >><br>
>> >> My configuration for building the fuzzers in the LLVM tree doesn't seem<br>
>> to<br>
>> >> work any more (possibly as of moving libFuzzer to compiler-rt, but there<br>
>> >> have been a few other changes in the last week or so that may be<br>
>> related).<br>
>> >><br>
>> >> I'm building with a fresh top-of-tree clang and setting<br>
>> >> -DLLVM_USE_SANITIZER=Address and -DLLVM_USE_SANITIZE_COVERAGE=<wbr>On, which<br>
>> >> was working before:<br>
>> >><br>
>> >> % cmake -GNinja \<br>
>> >> -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_ASSERTIONS=On \<br>
>> >> -DLLVM_ENABLE_WERROR=On \<br>
>> >> -DLLVM_USE_SANITIZER=Address -DLLVM_USE_SANITIZE_COVERAGE=<wbr>On \<br>
>> >> -DCMAKE_C_COMPILER=$HOME/llvm-<wbr>lkgc/bin/clang \<br>
>> >> $HOME/code/llvm-src<br>
>> >><br>
>> >> But when I run any of the fuzzers, it looks like the sanitizer coverage<br>
>> >> hasn't been set up correctly:<br>
>> >><br>
>> >> % ./bin/llvm-as-fuzzer<br>
>> 2017-08-24 11:14:33<br>
>> >> INFO: Seed: <a href="tel:4089166883" value="+14089166883">4089166883</a><br>
>> >> INFO: Loaded 1 modules (50607 guards): 50607 [0x10e14ef80,<br>
>> 0x10e18063c),<br>
>> >> INFO: Loaded 1 PC tables (0 PCs): 0 [0x10e2870a8,0x10e2870a8),<br>
>> >> ERROR: The size of coverage PC tables does not match the number of<br>
>> instrumented PCs. This might be a bug in the compiler, please contact the<br>
>> libFuzzer developers.<br>
>> >><br>
>> >> From the build logs, it looks like we're now building objects with these<br>
>> >> sanitizer flags:<br>
>> >><br>
>> >> -fsanitize=address<br>
>> >> -fsanitize-address-use-after-<wbr>scope<br>
>> >> -fsanitize=fuzzer-no-link<br>
>> >><br>
>> >> We're then linking the fuzzer binaries with these:<br>
>> >><br>
>> >> -fsanitize=address<br>
>> >> -fsanitize-address-use-after-<wbr>scope<br>
>> >> -fsanitize=fuzzer-no-link<br>
>> >> -fsanitize=fuzzer<br>
>> >><br>
>> >> Any idea what's wrong or where to start looking?<br>
>><br>
</div></div><div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Saleem Abdulrasool<br>compnerd (at) compnerd (dot) org</div>
</div></div>