<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi Alireza,<div class=""><br class=""></div><div><blockquote type="cite" class=""><div class="">On Oct 25, 2017, at 3:21 PM, Reid Kleckner <<a href="mailto:rnk@google.com" class="">rnk@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">On Wed, Oct 25, 2017 at 2:45 PM, Moshtaghi, Alireza via llvm-dev <span dir="ltr" class=""><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="white" lang="EN-US" link="blue" vlink="purple" class="">
<div class="m_4907974067443518833WordSection1"><p class="MsoNormal">Hi<u class=""></u><u class=""></u></p><p class="MsoNormal">I’m interested in implementing the solution for the header problem described in (1.) to emit coverage mappings to a side file and unique them when generating coverage reports. As you also mentioned this would require modifying the build
workflow. Can you explain how do you suggest changing the build workflow? I tried objcopy-ing the profile data sections from the “.o” files and relinking them again them again but that caused the (just to see if it is possible) but the output raw profile data
was not written into.<u class=""></u><u class=""></u></p><p class="MsoNormal"><u class=""></u> <u class=""></u></p><p class="MsoNormal">I’m open to trying any suggestion.</p></div></div></blockquote></div></div></div></div></blockquote><div class="">I sent out an RFC about emitting coverage mapping data outside of object files in June:</div><div class=""><a href="http://lists.llvm.org/pipermail/llvm-dev/2017-June/114855.html" class="">http://lists.llvm.org/pipermail/llvm-dev/2017-June/114855.html</a></div><div class=""><br class=""></div><div class="">There was a lot of feedback about that idea, so I encourage you to take a look at that thread. The two main take-aways (for me) were that:</div><div class="">1) The build system should know about the side files, so it can regenerate them and clean them up as needed</div><div class="">2) If we're going to use side-files, we should try to reuse existing linker and tooling support for split-DWARF as much as possible</div><div class=""><br class=""></div><div class="">I've heard arguments about the second point that cut both ways. It would be convenient to rely on linker support for not copying debug info sections into executables. OTOH, you'd need a tool like dsymutil to copy instrumented programs to a different machine.</div><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">Isn't that exactly what emitting the coverage data as linkonce_odr accomplishes?</div></div></div></div>
</div></blockquote></div><br class=""><div class="">Yeah, I'm in favor of trying this idea out first because it requires less work on linkers and build systems.</div><div class=""><br class=""></div><div class="">vedant</div></body></html>