[llvm-dev] Code coverage BoF - notes and updates

[Vedant Kumar via llvm-dev]

Hi Alireza,

> On Oct 25, 2017, at 3:21 PM, Reid Kleckner <rnk at google.com> wrote:
> 
> On Wed, Oct 25, 2017 at 2:45 PM, Moshtaghi, Alireza via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> Hi
> 
> 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.
> 
>  
> 
> I’m open to trying any suggestion.
> 
I sent out an RFC about emitting coverage mapping data outside of object files in June:
http://lists.llvm.org/pipermail/llvm-dev/2017-June/114855.html <http://lists.llvm.org/pipermail/llvm-dev/2017-June/114855.html>

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:
1) The build system should know about the side files, so it can regenerate them and clean them up as needed
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

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.

> Isn't that exactly what emitting the coverage data as linkonce_odr accomplishes?

Yeah, I'm in favor of trying this idea out first because it requires less work on linkers and build systems.

vedant
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171025/ecce9a95/attachment.html>