Skip to content
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

Merged
merged 17 commits into from
Jun 14, 2017

Conversation

marco-c
Copy link
Contributor

@marco-c marco-c commented Jun 4, 2017

r? @alexcrichton

This is #38608 with some fixes.

Still missing:

  • 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?);
  • enabling distribution (on which builders?);
  • documentation.

whitequark and others added 6 commits May 1, 2017 09:16
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.
@rust-highfive
Copy link
Collaborator

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.

@eddyb
Copy link
Member

eddyb commented Jun 5, 2017

cc @whitequark

@kennytm
Copy link
Member

kennytm commented Jun 5, 2017

I'm just wondering, aside from the name, is there any difference between #![sanitizer_runtime] and #![profiler_runtime], that leads to a distinct set of features?

@carols10cents carols10cents added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jun 5, 2017
@alexcrichton
Copy link
Member

Looking great, thanks for picking this up @marco-c!

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?);

I think this is supported on all platforms, right? If that's the case you can add --enable-sanitizers here. If not you can selectively enable it in particular builders, for example for x86_64-gnu you'd enable it here next to --enable-sanitizers. For OSX you'd do it here and on Windows you'd do it here.

enabling distribution (on which builders?)

This sort of depends on the point above. If we want to enable this on all platforms then src/ci/run.sh will do the trick. If not let's work out which builders need to distribute the profiler and we can figure that out.

documentation.

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.

@marco-c
Copy link
Contributor Author

marco-c commented Jun 5, 2017

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).

@marco-c
Copy link
Contributor Author

marco-c commented Jun 6, 2017

I'm just wondering, aside from the name, is there any difference between #![sanitizer_runtime] and #![profiler_runtime], that leads to a distinct set of features?

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.

@alexcrichton
Copy link
Member

Ah it looks like maybe this won't work with a system and/or older LLVM? Travis failed with:

[00:46:39] LLVM ERROR: IO failure on output stream.


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.
Copy link
Member

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?

Copy link
Contributor Author

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.

@kennytm
Copy link
Member

kennytm commented Jun 6, 2017

@marco-c Yes I understand the difference between sancov and gcov. But what I mean is, #![sanitizer_runtime] and #![profiler_runtime] only affect linker behavior ("link to this crate if -Zsanitizer=X/-Zprofile is used"). The reasons of split I can see are:

  • The profiler runtime is always a staticlib, while the sanitizer runtime are sometimes dylib
  • You can use -Zprofile and -Zsanitizer=X simultaneously

@kennytm
Copy link
Member

kennytm commented Jun 6, 2017

@alexcrichton I think it is because /checkout is read-only on Docker. Those *.gcno and *.gcda are placed "next to the existing source" (/checkout/src/test/run-make/profile/), so LLVM failed by writing to a read-only drive.

@marco-c
Copy link
Contributor Author

marco-c commented Jun 6, 2017

@alexcrichton I think it is because /checkout is read-only on Docker. Those *.gcno and *.gcda are placed "next to the existing source" (/checkout/src/test/run-make/profile/), so LLVM failed by writing to a read-only drive.

They should be placed in the output directory.
If you do:

mkdir target
rustc -g -Z profile main.rs --out-dir target

Both the binary and the gcno file will appear in the target directory.

The error does definitely seem related to failure in writing files though.

@marco-c
Copy link
Contributor Author

marco-c commented Jun 6, 2017

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?
Or should a newer LLVM be used on the builders?

@whitequark
Copy link
Member

@marco-c see #38608 (comment) re: LLVM version...

@alexcrichton
Copy link
Member

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 dist-i686-gnu and dist-x86_64-gnu docker images, 32-bit osx, 64-bit osx, and windows deployments

@alexcrichton
Copy link
Member

Can you change dist-x86_64-gnu and dist-i686-gnu in the src/ci/docker folder as well? (those are the Linux releases)

@marco-c
Copy link
Contributor Author

marco-c commented Jun 6, 2017

Can you change dist-x86_64-gnu and dist-i686-gnu in the src/ci/docker folder as well? (those are the Linux releases)

I changed dist-x86_64-linux and dist-i686-linux, as dist-x86_64-gnu and dist-i686-gnu don't exist :)

@alexcrichton
Copy link
Member

Oops sorry I missed that! Yeah as-is is fine

@arielb1 arielb1 removed the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Jun 13, 2017
@kennytm kennytm mentioned this pull request Jun 13, 2017
3 tasks
@bors
Copy link
Contributor

bors commented Jun 14, 2017

💔 Test failed - status-travis

@est31
Copy link
Member

est31 commented Jun 14, 2017

The job exceeded the maximum time limit for jobs, and has been terminated.

Maybe a retry will fix it.

@bors retry

@bors
Copy link
Contributor

bors commented Jun 14, 2017

⌛ Testing commit 5c084fd with merge 7375046...

@bors
Copy link
Contributor

bors commented Jun 14, 2017

💔 Test failed - status-appveyor

@alexcrichton
Copy link
Member

@bors: retry

@bors
Copy link
Contributor

bors commented Jun 14, 2017

⌛ Testing commit 5c084fd with merge 8af4502...

@bors
Copy link
Contributor

bors commented Jun 14, 2017

💔 Test failed - status-travis

@est31
Copy link
Member

est31 commented Jun 14, 2017

Spurious musl segfault (#38618)

@bors retry

@bors
Copy link
Contributor

bors commented Jun 14, 2017

⌛ Testing commit 5c084fd with merge dfa7e21...

bors added a commit that referenced this pull request Jun 14, 2017
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.
@bors
Copy link
Contributor

bors commented Jun 14, 2017

☀️ Test successful - status-appveyor, status-travis
Approved by: alexcrichton
Pushing dfa7e21 to master...

@sylvestre
Copy link
Contributor

Clap clap! 👍

@ofek
Copy link

ofek commented Jul 27, 2017

So now that this is merged, how can one test with coverage?

@kennytm
Copy link
Member

kennytm commented Jul 27, 2017

@ofek Same as https://jbp.io/2017/07/19/measuring-test-coverage-of-rust-programs, but use -Zprofile instead of -Cpasses=insert-gcov-profiling -L/usr/lib/llvm-3.8/lib/clang/3.8.1/lib/linux/ -lclang_rt.profile-x86_64.

@ofek
Copy link

ofek commented Jul 27, 2017

@kennytm Brilliant, thanks!

@marco-c marco-c deleted the profiling branch March 29, 2018 09:34
bors added a commit to rust-lang-ci/rust that referenced this pull request Oct 17, 2024
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
bors added a commit to rust-lang-ci/rust that referenced this pull request Oct 19, 2024
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.