[clang] [compiler-rt] [llvm] Add a field in Coverage Mapping header for tracking coverage capabilities (PR #158059)

[Dorian Péron via llvm-commits]

RenjiSann wrote:

> Thanks for submitting this! What you have here looks pretty straightforward. Unless I've totally missed it, I don't see the `llvm-profdata` merging capability handled or tested as we discussed on the discourse thread. I'd like to see that in as well so that merging is handled in a sound way.

Hi, sorry for taking so long to come back to this. While implementing this patch, I realized `llvm-profdata` does not seem to read the coverage header of a `profraw` file, it just merges everything, so it doesn't know about the coverage level used, and I think this wouldn't be right to make `llvm-profdata` look into the actual data just for this case, when it's not supposed to. Furthermore, I don't think this is an issue, as it seem that in order to merge `profraw` files, they must have been produced by the same binary, so theoritically, you can't merge `profraw`s that have a different coverage level (or at least that's what I understood while trying, but I'm no expert here).

Now, I thought about checking the available coverage level of instrumented object files in `llvm-cov` directly, but I was unsure about how to do it. The interface between llvm-cov and `CoverageMapping` loading takes all the object files in one call, and return a single CoverageMapping object, or an error.

Right now, `CoverageMapping::load` fails and returns an error if it encounters an object file that does not meet the coverage level requirements. I could turn this error into a warning, but I am not certain anymore if we should drop the "available instrumentation level" of other provided object files.



https://github.com/llvm/llvm-project/pull/158059