[cfe-dev] Absolute paths in code coverage info

[Vedant Kumar via cfe-dev]

> On Jun 2, 2020, at 5:17 PM, Keith Smiley <keithbsmiley at gmail.com> wrote:
> 
> FWIW after updating this patch I've verified that llvm-cov in the source directory with no `-path-equivalence` works fine, and also using `-path-equivalence=,$SRCROOT` works if you want to run it not from the source root.

That’s great to hear. I’ve cc’d Reid and Yuke who may have more context on this patch and any potential pitfalls with it.

> The latter might be a bit unexpected since folks may prefer `-path-equivalence=.,$SRCROOT` which I'm sure we could implement if that was the missing piece.

It might be sufficient to add a section to the llvm-cov command guide explaining how to use -fdebug-compilation-dir and -path-equivalence to get remote builds working.

> --
> Keith Smiley
> 
> 
> On Tue, Jun 2, 2020 at 2:49 PM Keith Smiley <keithbsmiley at gmail.com <mailto:keithbsmiley at gmail.com>> wrote:
> Ah actually it looks like that issue was resolved, but it was reverted a second time for:
> 
> > There seem to be bugs in llvm-cov --path-equivalence that are causing Chromium problems. Revert this until they are understood or fixed.
> 
> https://github.com/llvm/llvm-project/commit/7cd595df96d5929488063d8ff5cc3b5d800386da <https://github.com/llvm/llvm-project/commit/7cd595df96d5929488063d8ff5cc3b5d800386da>
> 
> Does anyone have more context on those?
> --
> Keith Smiley
> 
> 
> On Tue, Jun 2, 2020 at 2:27 PM Keith Smiley <keithbsmiley at gmail.com <mailto:keithbsmiley at gmail.com>> wrote:
> Thanks for the context! I found the revert https://github.com/llvm/llvm-project/commit/62808631acceaa8b78f8ab9b407eb6b943ff5f77 <https://github.com/llvm/llvm-project/commit/62808631acceaa8b78f8ab9b407eb6b943ff5f77> and it looks like it was caused by a small test issue. I'm a bit surprised by the justification for it since I would expect relying on the specific directory of the test to be safe, but I think I can make it work and re-submit.
> --
> Keith Smiley
> 
> 
> On Tue, Jun 2, 2020 at 10:44 AM Vedant Kumar <vsk at apple.com <mailto:vsk at apple.com>> wrote:
> A problem that absolute paths solve in local builds is dealing with a changing compilation directory - this can result in two different files being referenced by the same relative path.
> 
> There was a promising attempt to make this work with remote builds. The idea was to have the coverage mapping logic respect a fixed compilation directory option (https://reviews.llvm.org/D68733 <https://reviews.llvm.org/D68733>), i.e. the paths embedded in the coverage mapping should be rooted at the -fdebug-compilation-dir <path>. It looks like the patch was reverted, but (as far as I know) there aren’t any fundamental issues with it.
> 
>> On Jun 2, 2020, at 9:57 AM, Keith Smiley via cfe-dev <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote:
>> 
>> Hey everyone,
>> 
>> Currently when generating code coverage by passing `-fprofile-instr-generate -fcoverage-mapping` to clang, the __LLVM_COV / __llvm_covmap section ends up containing absolute paths to the source files being compiled. This causes issues when producing coverage info with remote builds where the absolute paths to the source files may differ between machines.
>> 
>> llvm-cov has a `-path-equivalence` flag in order for you to remap a single absolute path from the coverage info which definitely helps, but it doesn't solve this entirely for the cases where you have multiple paths that need remapping, or you're using another tool such as, Xcode's code coverage UI, that doesn't support this kind of path remapping.
>> 
>> I'm wondering if it has been discussed, or how feasible it would be, for me to remove the necessity for absolute paths in this info.
>> 
>> Thanks!
>> --
>> Keith Smiley
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev <https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200603/b8331ca9/attachment.html>