<div dir="ltr"><div>FTR: </div><div>r<a href="http://llvm.org/viewvc/llvm-project?rev=311719&view=rev" rel="noreferrer" target="_blank" style="font-size:12.8px">311719</a> adds the docs for -fsanitize-coverage=pc-table and -fsanitize-coverage=inline-8bit-counters<br></div><div><a href="https://clang.llvm.org/docs/SanitizerCoverage.html#inline-8bit-counters">https://clang.llvm.org/docs/SanitizerCoverage.html#inline-8bit-counters</a><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 24, 2017 at 3:38 PM, Kostya Serebryany <span dir="ltr"><<a href="mailto:kcc@google.com" target="_blank">kcc@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Thu, Aug 24, 2017 at 3:35 PM, Peter Collingbourne <span dir="ltr"><<a href="mailto:peter@pcc.me.uk" target="_blank">peter@pcc.me.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="m_1510688294290790613gmail-">On Thu, Aug 24, 2017 at 3:21 PM, Kostya Serebryany 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Thu, Aug 24, 2017 at 3:20 PM, Justin Bogner <span dir="ltr"><<a href="mailto:mail@justinbogner.com" target="_blank">mail@justinbogner.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I think the simplest fix is something like this:<br>
<br>
diff --git a/lib/Transforms/Instrumentati<wbr>on/SanitizerCoverage.cpp b/lib/Transforms/Instrumentati<wbr>on/SanitizerCoverage.cpp<br>
index c6f0d17f8fe..e81957ab80a 100644<br>
--- a/lib/Transforms/Instrumentati<wbr>on/SanitizerCoverage.cpp<br>
+++ b/lib/Transforms/Instrumentati<wbr>on/SanitizerCoverage.cpp<br>
@@ -256,6 +256,7 @@ SanitizerCoverageModule::Creat<wbr>eSecStartEnd(Module &M, const char *Section,<br>
new GlobalVariable(M, Ty, false, GlobalVariable::ExternalLinkag<wbr>e,<br>
nullptr, getSectionEnd(Section));<br>
SecEnd->setVisibility(GlobalV<wbr>alue::HiddenVisibility);<br>
+ appendToUsed(M, {SecStart, SecEnd});<br>
<br>
return std::make_pair(SecStart, SecEnd);<br>
}<br>
<br>
I'm trying it out now.<br></blockquote><div><br></div></span><div>LGTM (if this works), thanks! </div></div></div></div></blockquote><div><br></div></span><div>I wouldn't expect that to work because for ELF targets llvm.used has no effect on the object file (only on the optimizer).</div><div><br></div><div>Is there a simple way to reproduce the link failure?</div></div></div></div></blockquote><div><br></div><div><br></div></span><div>ninja compiler-rt <br></div><div>echo 'extern "C" int LLVMFuzzerTestOneInput(const unsigned char *a, unsigned long b){return 0; } ' > test.cc<br></div><div>clang -O3 test.cc -fsanitize=fuzzer # works<br></div><div>clang -O3 test.cc -Wl,-gc-sections -fsanitize=fuzzer # fails<br></div><div><div class="h5"><div><br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>Peter</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div class="m_1510688294290790613gmail-h5"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div class="m_1510688294290790613gmail-m_224970283969396481h5"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span><br>
Kostya Serebryany <<a href="mailto:kcc@google.com" target="_blank">kcc@google.com</a>> writes:<br>
> With -Wl,-gc-sections I get this:<br>
> SimpleTest.cpp:(.text.sancov.m<wbr>odule_ctor[sancov.module_ctor]<wbr>+0x1b):<br>
> undefined reference to `__start___sancov_pcs'<br>
> SimpleTest.cpp:(.text.sancov.m<wbr>odule_ctor[sancov.module_ctor]<wbr>+0x20):<br>
> undefined reference to `__stop___sancov_pcs'<br>
><br>
><br>
><br>
> On Thu, Aug 24, 2017 at 3:07 PM, George Karpenkov <<a href="mailto:ekarpenkov@apple.com" target="_blank">ekarpenkov@apple.com</a>><br>
> wrote:<br>
><br>
>><br>
>> On Aug 24, 2017, at 2:55 PM, Kostya Serebryany <<a href="mailto:kcc@google.com" target="_blank">kcc@google.com</a>> wrote:<br>
>><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>
>><br>
>> For tests we never compile the tested target with -O3 (and that wouldn’t<br>
>> be sufficient),<br>
>> and for testing fuzzers I was always building them in debug<br>
>><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>
>><br>
>> Do you know what's the analog of Wl,-dead_strip on Linux?<br>
>><br>
>><br>
>> Apparently -Wl,—gc-sections.<br>
>> For some reason LLVM does not do it for gold, even though it seems to<br>
>> support this flag as well.<br>
>> (that could be another reason why you don’t see the failure on Linux)<br>
>><br>
</span>>> 1 *if*(NOT LLVM_NO_DEAD_STRIP)<br>
>> 2 *if*(${CMAKE_SYSTEM_NAME} MATCHES "Darwin")<br>
<span>>> 3 # ld64's implementation of -dead_strip breaks tools that use<br>
>> plugins.<br>
>> 4 set_property(TARGET ${target_name} APPEND_STRING PROPERTY<br>
>> 5 LINK_FLAGS " -Wl,-dead_strip")<br>
</span>>> 6 *elseif*(${CMAKE_SYSTEM_NAME} MATCHES "SunOS")<br>
<span>>> 7 set_property(TARGET ${target_name} APPEND_STRING PROPERTY<br>
>> 8 LINK_FLAGS " -Wl,-z -Wl,discard-unused=sections")<br>
</span>>> 9 *elseif*(NOT WIN32 AND NOT LLVM_LINKER_IS_GOLD)<br>
<span>>> 10 # Object files are compiled with -ffunction-data-sections.<br>
>> 11 # Versions of bfd ld < 2.23.1 have a bug in --gc-sections that<br>
>> breaks<br>
>> 12 # tools that use plugins. Always pass --gc-sections once we require<br>
>> 13 # a newer linker.<br>
>> 14 set_property(TARGET ${target_name} APPEND_STRING PROPERTY<br>
>> 15 LINK_FLAGS " -Wl,--gc-sections")<br>
</span>>> 16 *endif*()<br>
>> 17 *endif*()<br>
<div class="m_1510688294290790613gmail-m_224970283969396481m_8917638551223592181HOEnZb"><div class="m_1510688294290790613gmail-m_224970283969396481m_8917638551223592181h5">>><br>
>><br>
>><br>
>> --kcc<br>
>><br>
>><br>
>><br>
>> On Thu, Aug 24, 2017 at 2:49 PM, Justin Bogner <<a href="mailto:mail@justinbogner.com" target="_blank">mail@justinbogner.com</a>><br>
>> wrote:<br>
>><br>
>>> George Karpenkov <<a href="mailto:ekarpenkov@apple.com" target="_blank">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/HandleLLVMOpti<wbr>ons.cmake<br>
>>> b/cmake/modules/HandleLLVMOpti<wbr>ons.cmake<br>
>>> > index 04596a6ff63..5465d8d95ba 100644<br>
>>> > --- a/cmake/modules/HandleLLVMOpti<wbr>ons.cmake<br>
>>> > +++ b/cmake/modules/HandleLLVMOpti<wbr>ons.cmake<br>
>>> > @@ -665,6 +665,9 @@ if(LLVM_USE_SANITIZER)<br>
>>> > endif()<br>
>>> > if (LLVM_USE_SANITIZE_COVERAGE)<br>
>>> > append("-fsanitize=fuzzer-no-l<wbr>ink" 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" target="_blank">mail@justinbogner.com</a>><br>
>>> wrote:<br>
>>> >><br>
>>> >> (kcc, george: sorry for the re-send, the first was from a non-list<br>
>>> email<br>
>>> >> address)<br>
>>> >><br>
>>> >> My configuration for building the fuzzers in the LLVM tree doesn't<br>
>>> seem to<br>
>>> >> work any more (possibly as of moving libFuzzer to compiler-rt, but<br>
>>> 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=O<wbr>n,<br>
>>> 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=O<wbr>n<br>
>>> \<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:(408)%20916-6883" value="+14089166883" target="_blank">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<br>
>>> these<br>
>>> >> sanitizer flags:<br>
>>> >><br>
>>> >> -fsanitize=address<br>
>>> >> -fsanitize-address-use-after-s<wbr>cope<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-s<wbr>cope<br>
>>> >> -fsanitize=fuzzer-no-link<br>
>>> >> -fsanitize=fuzzer<br>
>>> >><br>
>>> >> Any idea what's wrong or where to start looking?<br>
>>><br>
>><br>
>><br>
>><br>
</div></div></blockquote></div></div></div><br></div></div>
<br></div></div>______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">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>
<br></blockquote></div><span class="m_1510688294290790613gmail-HOEnZb"><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div class="m_1510688294290790613gmail-m_224970283969396481gmail_signature"><div dir="ltr">-- <div>Peter</div></div></div>
</font></span></div></div>
</blockquote></div></div></div><br></div></div>
</blockquote></div><br></div>