-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Build instruction profiler runtime as part of compiler-rt #42433
Conversation
When -Z profile is passed, the GCDAProfiling LLVM pass is added to the pipeline, which uses debug information to instrument the IR. After compiling with -Z profile, the $(OUT_DIR)/$(CRATE_NAME).gcno file is created, containing initial profiling information. After running the program built, the $(OUT_DIR)/$(CRATE_NAME).gcda file is created, containing branch counters. The created *.gcno and *.gcda files can be processed using the "llvm-cov gcov" and "lcov" tools. The profiling data LLVM generates does not faithfully follow the GCC's format for *.gcno and *.gcda files, and so it will probably not work with other tools (such as gcov itself) that consume these files.
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @alexcrichton (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
cc @whitequark |
I'm just wondering, aside from the name, is there any difference between |
Looking great, thanks for picking this up @marco-c!
I think this is supported on all platforms, right? If that's the case you can add
This sort of depends on the point above. If we want to enable this on all platforms then
FWIW I'm not thinking anything fancy here, just a "hello world" documentation thing inside of src/doc/unstable-book/src/compiler-flags/profile.md. |
I've added some basic documentation, without going into detail into how to parse the gcno/gcda files, as I thought it was out of scope (if you think it isn't, I can describe in more detail how to generate a report using lcov and genhtml). |
The profiler instruments the binary to collect coverage data, the sanitizers (there are many different sanitizers) are mostly used to detect memory/threading errors. The sanitizers can also be used to collect coverage data (https://clang.llvm.org/docs/SanitizerCoverage.html), but the output isn't compatible with gcov that is the most widely used tool. |
Ah it looks like maybe this won't work with a system and/or older LLVM? Travis failed with:
|
|
||
This feature allows the generation of code coverage reports. | ||
|
||
Set the compiler flags `-Ccodegen-units=1 -Clink-dead-code -Cpasses=insert-gcov-profiling -Zno-landing-pads` to enable gcov profiling. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't -Z profile
be mentioned here? If all these other flags are required, could -Z profile
imply them?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, I think they aren't strictly required. I've replaced them with -Zprofile
.
@marco-c Yes I understand the difference between sancov and gcov. But what I mean is,
|
@alexcrichton I think it is because |
They should be placed in the output directory.
Both the binary and the gcno file will appear in the The error does definitely seem related to failure in writing files though. |
Oh, wait a second, the builder has LLVM 3.7, but the three-element variant of the llvm.gcov metadata is only supported from LLVM 3.9. @alexcrichton should I revert back to the old two-element variant that is also supported on LLVM < 3.9? |
@marco-c see #38608 (comment) re: LLVM version... |
Ok in that case we won't want to blanket enable this across all builders (as this is known to fail on at least one). Let's enable three testing builders for OSX/Windows/Linux as mentioned above and then let's similarly modify the builders that produce releases for these platforms. You can do that by modifying |
Can you change |
I changed |
Oops sorry I missed that! Yeah as-is is fine |
💔 Test failed - status-travis |
Maybe a retry will fix it. @bors retry |
⌛ Testing commit 5c084fd with merge 7375046... |
💔 Test failed - status-appveyor |
@bors: retry |
⌛ Testing commit 5c084fd with merge 8af4502... |
💔 Test failed - status-travis |
Build instruction profiler runtime as part of compiler-rt r? @alexcrichton This is #38608 with some fixes. Still missing: - [x] testing with profiler enabled on some builders (on which ones? Should I add the option to some of the already existing configurations, or create a new configuration?); - [x] enabling distribution (on which builders?); - [x] documentation.
☀️ Test successful - status-appveyor, status-travis |
Clap clap! 👍 |
So now that this is merged, how can one test with coverage? |
@ofek Same as https://jbp.io/2017/07/19/measuring-test-coverage-of-rust-programs, but use |
@kennytm Brilliant, thanks! |
Make `profiler_builtins` an optional dependency of sysroot, not std This avoids unnecessary rebuilds of std (and the compiler) when `build.profiler` is toggled off or on. Fixes rust-lang#131812. --- Background: The `profiler_builtins` crate has been an optional dependency of std (behind a cargo feature) ever since it was added back in rust-lang#42433. But as far as I can tell that has only ever been a convenient way to force the crate to be built, not a genuine dependency. The side-effect of this false dependency is that toggling `build.profiler` causes a rebuild of std and the compiler, which shouldn't be necessary. This PR therefore makes `profiler_builtins` an optional dependency of the dummy sysroot crate (rust-lang#108865), rather than a dependency of std. What makes this change so small is that all of the necessary infrastructure already exists. Previously, bootstrap would enable the `profiler` feature on the sysroot crate, which would forward that feature to std. Now, enabling that feature directly enables sysroot's `profiler_builtins` dependency instead. --- I believe this is more of a bootstrap change than a libs change, so tentatively: r? bootstrap
Make `profiler_builtins` an optional dependency of sysroot, not std This avoids unnecessary rebuilds of std (and the compiler) when `build.profiler` is toggled off or on. Fixes rust-lang#131812. --- Background: The `profiler_builtins` crate has been an optional dependency of std (behind a cargo feature) ever since it was added back in rust-lang#42433. But as far as I can tell that has only ever been a convenient way to force the crate to be built, not a genuine dependency. The side-effect of this false dependency is that toggling `build.profiler` causes a rebuild of std and the compiler, which shouldn't be necessary. This PR therefore makes `profiler_builtins` an optional dependency of the dummy sysroot crate (rust-lang#108865), rather than a dependency of std. What makes this change so small is that all of the necessary infrastructure already exists. Previously, bootstrap would enable the `profiler` feature on the sysroot crate, which would forward that feature to std. Now, enabling that feature directly enables sysroot's `profiler_builtins` dependency instead. --- I believe this is more of a bootstrap change than a libs change, so tentatively: r? bootstrap
r? @alexcrichton
This is #38608 with some fixes.
Still missing: