Build instruction profiler runtime as part of compiler-rt by marco-c · Pull Request #42433 · rust-lang/rust

marco-c · 2017-06-04T19:56:58Z

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.

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 · 2017-06-04T19:57:10Z

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 · 2017-06-05T07:47:27Z

cc @whitequark

kennytm · 2017-06-05T08:32:46Z

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?

alexcrichton · 2017-06-05T18:42:20Z

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-sanitizershere. 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 · 2017-06-05T23:40:26Z

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 · 2017-06-06T00:34:43Z

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 · 2017-06-06T01:11:02Z

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.

alexcrichton · 2017-06-06T01:11:39Z

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


Shouldn't -Z profile be mentioned here? If all these other flags are required, could -Z profile imply them?

Right, I think they aren't strictly required. I've replaced them with -Zprofile.

kennytm · 2017-06-06T02:30:42Z

@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 · 2017-06-06T02:43:32Z

@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 · 2017-06-06T11:19:30Z

@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 · 2017-06-06T11:49:56Z

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 · 2017-06-06T12:15:33Z

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

alexcrichton · 2017-06-06T14:06:10Z

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 · 2017-06-06T14:31:36Z

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 · 2017-06-06T14:34:36Z

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 · 2017-06-06T14:36:57Z

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

bors · 2017-06-14T00:40:06Z

💔 Test failed - status-travis

est31 · 2017-06-14T01:20:54Z

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

Maybe a retry will fix it.

@bors retry

bors · 2017-06-14T02:56:41Z

⌛ Testing commit 5c084fd with merge 7375046...

bors · 2017-06-14T03:01:15Z

💔 Test failed - status-appveyor

alexcrichton · 2017-06-14T03:20:15Z

@bors: retry

bors · 2017-06-14T07:12:34Z

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

bors · 2017-06-14T08:18:17Z

💔 Test failed - status-travis

est31 · 2017-06-14T08:29:24Z

Spurious musl segfault (#38618)

@bors retry

bors · 2017-06-14T08:46:22Z

⌛ Testing commit 5c084fd with merge dfa7e21...

@alexcrichton

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 · 2017-06-14T11:17:27Z

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

sylvestre · 2017-06-15T13:19:20Z

Clap clap! 👍

ofek · 2017-07-27T02:30:22Z

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

kennytm · 2017-07-27T04:33:43Z

@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 · 2017-07-27T04:36:42Z

@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. Fixesrust-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

whitequarkand others added 6 commits May 1, 2017 09:16

Merge branch 'profiling' of github.com:whitequark/rust into profiling
ecba8d6

Stop checking uses_std
60524c5

Add llvm.gcov metadata only if profiler is enabled
a1ca5f6

Run profiler test only if built with profiler support
0b0a5ac

Use the three-element variant of the 'llvm.gcov' metadata
8b7826f

rust-highfive assigned alexcrichton Jun 4, 2017

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

marco-c added 2 commits June 5, 2017 23:56

Enable profiler on all builders
26ad8d4

Add basic documentation for the profile feature
84d1626

Spell profiler option correctly...
13b3c34

alexcrichton reviewed Jun 6, 2017
View reviewed changes

Suggest 'profile' flag
95c6fc4

marco-c force-pushed the profiling branch from 7205f78 to 43eaa1bCompare June 6, 2017 14:18

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 mentioned this pull request Jun 13, 2017
Support -Zprofilekennytm/cov#10
Closed
3 tasks

bors merged commit 5c084fd into rust-lang:masterJun 14, 2017

This was referenced Jun 14, 2017
Implement From<&[T]> and others for Arc/Rc (RFC 1845) #42565
Merged
Bump to 1.20.0 and update stage0 compiler #42495
Merged

SimonSapin mentioned this pull request Jul 10, 2017
Is (cross-)compiling with an "alt" compiler and "non-alt" standard library supported? #43085
Closed

marco-c mentioned this pull request Sep 19, 2017
Generate gcov coverage data rust-lang/rfcs#646
Closed

marco-c deleted the profiling branch March 29, 2018 09:34

ldm0 mentioned this pull request Sep 10, 2022
build-std compatible profile(code coverage) support #101392
Closed

This was referenced Oct 17, 2024
Changing build.profiler forces an unnecessary rebuild of std #131812
Closed
Make profiler_builtins an optional dependency of sysroot, not std #131816
Merged


		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.

Uh oh!

Uh oh!

Conversation

marco-c commented Jun 4, 2017• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rust-highfive commented Jun 4, 2017

Uh oh!

eddyb commented Jun 5, 2017

Uh oh!

kennytm commented Jun 5, 2017

Uh oh!

alexcrichton commented Jun 5, 2017

Uh oh!

marco-c commented Jun 5, 2017

Uh oh!

marco-c commented Jun 6, 2017

Uh oh!

alexcrichton commented Jun 6, 2017

Uh oh!

alexcrichtonJun 6, 2017

Choose a reason for hiding this comment

Uh oh!

marco-cJun 6, 2017

Choose a reason for hiding this comment

Uh oh!

kennytm commented Jun 6, 2017

Uh oh!

kennytm commented Jun 6, 2017• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

marco-c commented Jun 6, 2017

Uh oh!

marco-c commented Jun 6, 2017

Uh oh!

whitequark commented Jun 6, 2017

Uh oh!

alexcrichton commented Jun 6, 2017

Uh oh!

alexcrichton commented Jun 6, 2017

Uh oh!

marco-c commented Jun 6, 2017

Uh oh!

alexcrichton commented Jun 6, 2017

Uh oh!

bors commented Jun 14, 2017

Uh oh!

est31 commented Jun 14, 2017

Uh oh!

bors commented Jun 14, 2017

Uh oh!

bors commented Jun 14, 2017

Uh oh!

alexcrichton commented Jun 14, 2017

Uh oh!

bors commented Jun 14, 2017

Uh oh!

bors commented Jun 14, 2017

Uh oh!

est31 commented Jun 14, 2017

Uh oh!

bors commented Jun 14, 2017

Uh oh!

bors commented Jun 14, 2017

Uh oh!

sylvestre commented Jun 15, 2017

Uh oh!

ofek commented Jul 27, 2017

Uh oh!

kennytm commented Jul 27, 2017

Uh oh!

ofek commented Jul 27, 2017

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

marco-c commented Jun 4, 2017•
edited
Loading

kennytm commented Jun 6, 2017•
edited
Loading