
<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jun 3, 2020, at 2:38 PM, Petr Hosek <<a href="mailto:phosek@chromium.org" class="">phosek@chromium.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">Would there be any opposition against supporting -ffile-prefix-map in coverage mappings in addition to -fdebug-compilation-dir? We hit this issue recently as well, and I was thinking about implementing a similar change for -ffile-prefix-map.</div></div></div></blockquote><div><br class=""></div><div>I think it’s a good idea.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">One potential issue is that -ffile-prefix-map isn't currently passed to cc1, rather it implies --debug-prefix-map but I'm not sure if we want to make change semantics of that flag to apply to coverage as well which would affect existing users of -fdebug-prefix-map,</div></div></div></blockquote><div><br class=""></div>Thanks for flagging this. You’re right, changing the absolute path behavior under -fdebug-prefix-map might break llvm-cov workflows which aren’t using -path-equivalence. -ffile-prefix-map seems relatively new, and also its purpose is to be a ‘union’ of other *prefix-map options, so having this imply —coverage-prefix-map makes sense to me.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""> maybe we should introduce a new cc1 flag, e.g. --coverage-prefix-map, which would be also implied by -ffile-prefix-map.</div></div></div></blockquote><div><br class=""></div><div>Sounds good to me. But for consistency, maybe we should rethink how -fdebug-compilation-dir <relpath> is handled. A couple options:</div><div><br class=""></div><div>- Have `-fdebug-compilation-dir <relpath>` (driver flag) imply `—coverage-prefix-map=$(abspath <relpath>)=./` (cc1 flag).</div><div><br class=""></div><div>The absolute path is hidden from the driver invocation, so this can still be used by a caching build system. I’m assuming we don’t embed the cc1 flags anywhere, e.g. not in the DW_AT_APPLE_flags. This is the closest to what <a href="https://reviews.llvm.org/D81122" class="">https://reviews.llvm.org/D81122</a> is currently doing.</div><div><br class=""></div><div>- Introduce `-ffile-compilation-dir <relpath>` (driver flag), which implies `-fdebug-compilation-dir <relpath>` (cc1 flag) and a new `-fcoverage-compilation-dir <relpath>`</div><div><br class=""></div><div>Essentially, make -ffile-compilation-dir analogous to -ffile-prefix-map, a union of *compilation-dir options.</div><div><br class=""></div><div>vedant</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jun 3, 2020 at 11:09 AM Vedant Kumar via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jun 2, 2020, at 5:17 PM, Keith Smiley <<a href="mailto:keithbsmiley@gmail.com" target="_blank" class="">keithbsmiley@gmail.com</a>> wrote:</div><br class=""><div class=""><div dir="ltr" class="">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.</div></div></blockquote><div class=""><br class=""></div><div class="">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.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""> 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.<br clear="all" class=""></div></div></blockquote><div class=""><br class=""></div><div class="">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.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><div dir="ltr" class="">--<br class="">Keith Smiley<br class=""></div></div><br class=""></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 2, 2020 at 2:49 PM Keith Smiley <<a href="mailto:keithbsmiley@gmail.com" target="_blank" class="">keithbsmiley@gmail.com</a>> wrote:<br class=""></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" class="">Ah actually it looks like that issue was resolved, but it was reverted a second time for:<div class=""><br class=""></div><div class="">> There seem to be bugs in llvm-cov --path-equivalence that are causing Chromium problems. Revert this until they are understood or fixed.</div><div class=""><br class=""></div><div class=""><a href="https://github.com/llvm/llvm-project/commit/7cd595df96d5929488063d8ff5cc3b5d800386da" target="_blank" class="">https://github.com/llvm/llvm-project/commit/7cd595df96d5929488063d8ff5cc3b5d800386da</a></div><div class=""><br class=""></div><div class="">Does anyone have more context on those?<br class=""><div class=""><div dir="ltr" class="">--<br class="">Keith Smiley<br class=""></div></div><br class=""></div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 2, 2020 at 2:27 PM Keith Smiley <<a href="mailto:keithbsmiley@gmail.com" target="_blank" class="">keithbsmiley@gmail.com</a>> wrote:<br class=""></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" class="">Thanks for the context! I found the revert <a href="https://github.com/llvm/llvm-project/commit/62808631acceaa8b78f8ab9b407eb6b943ff5f77" target="_blank" class="">https://github.com/llvm/llvm-project/commit/62808631acceaa8b78f8ab9b407eb6b943ff5f77</a> 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.<br clear="all" class=""><div class=""><div dir="ltr" class="">--<br class="">Keith Smiley<br class=""></div></div><br class=""></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 2, 2020 at 10:44 AM Vedant Kumar <<a href="mailto:vsk@apple.com" target="_blank" class="">vsk@apple.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="">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.<div class=""><br class=""></div><div class="">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 (<a href="https://reviews.llvm.org/D68733" target="_blank" class="">https://reviews.llvm.org/D68733</a>), 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.</div><div class=""><br class=""></div><div class=""><div class=""><div class=""><blockquote type="cite" class=""><div class="">On Jun 2, 2020, at 9:57 AM, Keith Smiley via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a>> wrote:</div><br class=""><div class=""><div dir="ltr" class="">Hey everyone,<div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Thanks!<br clear="all" class=""><div class=""><div dir="ltr" class="">--<br class="">Keith Smiley<br class=""></div></div></div></div>

_______________________________________________<br class="">cfe-dev mailing list<br class=""><a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a><br class=""><a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" target="_blank" class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br class=""></div></blockquote></div><br class=""></div></div></div></blockquote></div>

</blockquote></div>

</blockquote></div>

</div></blockquote></div><br class=""></div>_______________________________________________<br class="">

cfe-dev mailing list<br class="">

<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a><br class="">

<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank" class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br class="">

</blockquote></div></div>

</div></blockquote></div><br class=""></body></html>