-
Notifications
You must be signed in to change notification settings - Fork 13.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Invalid LLVM coverage data produced with crate brotli_decompressor #82875
Comments
I believe I have a working fix for this. It is apparently not a dup of #82144 but may be related. The fix I applied is a change in } else if list_contains_name(&items[..], sym::always) {
if tcx.sess.opts.debugging_opts.instrument_coverage {
InlineAttr::Hint
} else {
InlineAttr::Always
} I want to make a note of this, but I'm also investigating an idea that may (possibly) allow LLVM inlining. If that fix works, I may be able to enable LLVM optimization, and this workaround would not be necessary. What's happening is, I'm not sure if there is an LLVM flag we can apply today, to turn that off, or if that's even a good idea. But this fix would seem to disable inlining of all Rust functions, as long as LLVM optimization is NOT applied. The sample code works with this fix. I'll be submitting a PR in the near future with either this fix or a better one, if I confirm I can enable LLVM inlining after all. cc: @tmandry @wesleywiser |
Thanks, looking forward to the fix |
…=tmandry coverage bug fixes and optimization support Adjusted LLVM codegen for code compiled with `-Zinstrument-coverage` to address multiple, somewhat related issues. Fixed a significant flaw in prior coverage solution: Every counter generated a new counter variable, but there should have only been one counter variable per function. This appears to have bloated .profraw files significantly. (For a small program, it increased the size by about 40%. I have not tested large programs, but there is anecdotal evidence that profraw files were way too large. This is a good fix, regardless, but hopefully it also addresses related issues. Fixes: rust-lang#82144 Invalid LLVM coverage data produced when compiled with -C opt-level=1 Existing tests now work up to at least `opt-level=3`. This required a detailed analysis of the LLVM IR, comparisons with Clang C++ LLVM IR when compiled with coverage, and a lot of trial and error with codegen adjustments. The biggest hurdle was figuring out how to continue to support coverage results for unused functions and generics. Rust's coverage results have three advantages over Clang's coverage results: 1. Rust's coverage map does not include any overlapping code regions, making coverage counting unambiguous. 2. Rust generates coverage results (showing zero counts) for all unused functions, including generics. (Clang does not generate coverage for uninstantiated template functions.) 3. Rust's unused functions produce minimal stubbed functions in LLVM IR, sufficient for including in the coverage results; while Clang must generate the complete LLVM IR for each unused function, even though it will never be called. This PR removes the previous hack of attempting to inject coverage into some other existing function instance, and generates dedicated instances for each unused function. This change, and a few other adjustments (similar to what is required for `-C link-dead-code`, but with lower impact), makes it possible to support LLVM optimizations. Fixes: rust-lang#79651 Coverage report: "Unexecuted instantiation:..." for a generic function from multiple crates Fixed by removing the aforementioned hack. Some "Unexecuted instantiation" notices are unavoidable, as explained in the `used_crate.rs` test, but `-Zinstrument-coverage` has new options to back off support for either unused generics, or all unused functions, which avoids the notice, at the cost of less coverage of unused functions. Fixes: rust-lang#82875 Invalid LLVM coverage data produced with crate brotli_decompressor Fixed by disabling the LLVM function attribute that forces inlining, if `-Z instrument-coverage` is enabled. This attribute is applied to Rust functions with `#[inline(always)], and in some cases, the forced inlining breaks coverage instrumentation and reports. FYI: `@wesleywiser` r? `@tmandry`
I tried this code:
compiled with
RUSTFLAGS="-Zinstrument-coverage"
and Cargo.toml having
I expected to see this happen:
Running
echo 123 | ./target/debug/rustcov
thenllvm-profdata merge -j=1 -sparse
, then llvm-cov should give me a coverage reportInstead, this happened:
llvm-cov fails with `Failed to load coverage: Malformed instrumentation profile data
Meta
rustc --version --verbose
:Backtrace
There is no backtrace here as the failure happens with llvm-cov
I used the following clang
Using this patch in llvm
I get more information with, as llvm-cov prints
function with hash 66eebda9c13062cc has no name
cc @richkadel
Might end up as a duplicate of #82144
But I do not see any optimization in cargo build -vv
The text was updated successfully, but these errors were encountered: