[PATCH] D95753: [CoverageMapping] Don't absolutize source paths

[Petr Hosek via Phabricator via cfe-commits]

phosek added a comment.

In D95753#2534061 <https://reviews.llvm.org/D95753#2534061>, @vsk wrote:

> For context, the reason abspaths are used here is because users don't expect coverage results to go missing if the build directory changes (e.g. given `cd A; cc x.c; cd ../B; cc x.c`, the expectation is that coverage for two distinct x.c's is reported).
>
> I think it's important that this continues to work by default. Default-enabling the suggested `-fcoverage-mapping-abspath` option sounds like a workable solution. I haven't kept up with the work on -f(debug-)?compilation-dir, but if that option were specified, it could make sense to make coverage filenames "absolute" (relative to `chroot <compilation-dir>`).

That's a useful context, thank you!

In the case of debug info, we store the compilation directory (`DW_AT_comp_dir`)  separately from the file (`DW_AT_decl_file`) so even if we use relative path for the file by default, you can still get the absolute path by concatenating it with the directory which is absolute by default. In the case of coverage, there's no separate directory field, hence using the absolute path by default.

To produce a fully relocatable debug info, you can use `-fdebug-compilation-dir .`, but then it's the responsibility of the developer/build system to ensure that processing is done from the correct build directory to avoid the issue you mentioned. Given that, I think it makes sense to similarly gate the use of relative paths in coverage mapping on a flag.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D95753/new/

https://reviews.llvm.org/D95753