Build instruction profiler runtime as part of compiler-rt

[marco-c]

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.

[rust-highfive]

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]

cc @whitequark

[kennytm]

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]

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]

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]

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]

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]

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

[marco-c]

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

[kennytm]

@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]

@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]

@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]

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]

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

[alexcrichton]

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]

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]

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]

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

[alexcrichton]

@bors: r+

[bors]

📌 Commit 5c084fd has been approved by alexcrichton

[bors]

⌛ Testing commit 5c084fd with merge 6b2faa5...

[bors]

💔 Test failed - status-travis

[est31]

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

Maybe a retry will fix it.

@bors retry

[bors]

⌛ Testing commit 5c084fd with merge 7375046...

[bors]

💔 Test failed - status-appveyor

[alexcrichton]

@bors: retry

[bors]

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

[bors]

💔 Test failed - status-travis

[est31]

Spurious musl segfault (#38618)

@bors retry

[bors]

⌛ Testing commit 5c084fd with merge dfa7e21...

[bors]

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

[sylvestre]

Clap clap! 👍

[ofek]

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

[kennytm]

@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]

@kennytm Brilliant, thanks!