Add -C link-dead-code option (to improve kcov code coverage) #31368
Conversation
|
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @jroesch (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. |
|
See also https://internals.rust-lang.org/t/disabling-gc-sections-when-test-is-specified/2163 for some discussion of doing this. |
|
Thanks for the link @sfackler! I'm glad there's some documentation on this topic. Based on the thread, this might not be the best solution for everybody. Then, I guess I can close this PR, until a there's a consensus. |
|
Thanks for the PR @JohanLorenzo! I'm always happy to see movement on this :). I think that the best option that came out of @sfackler's link is that for now it's probably best to not have I think that we can end up passing this down to Cargo via either the profile idea that @huonw mentioned or perhaps the |
|
Oh and it looks like a flag like that has even been requested before! |
|
Thanks for the feedback @alexcrichton. Here's a new revision that implements -C no-gc-sections asked in #17141. |
| // reduction. | ||
| } else if !is_dylib { | ||
| self.cmd.arg("-Wl,--gc-sections"); | ||
| if !self.sess.opts.cg.no_gc_sections { |
There was a problem hiding this comment.
This diff would be very short if you just did
if !self.sess.opts.cg.no_gc_sections {
return;
}There was a problem hiding this comment.
(but also, I am the kind of person that would put the conditional check around the call-site to linker.gc_sections(..); this change is making this function act more like fn maybe_gc_sections(..))
There was a problem hiding this comment.
Good point. I'll wrap the call instead.
|
@JohanLorenzo If you're interested in trying to make a test of this functionality, I bet you might be able to do it with a |
|
|
||
| # Should contain gc-sections... | ||
| $(RUSTC) -Z print-link-args dummy.rs 2>&1 | \ | ||
| grep '"-Wl,--gc-sections"' |
There was a problem hiding this comment.
I discussed with @pnkfelix about testing also on IRC. A better approach would be to use
objdump --disassemble $(TMPDIR)/dummy | grep 'unused_function'I tried to implement this check, but it turns out $(TMPDIR)/dummy is not accessible when run in the Makefile. When I ran the same command locally, it works like a charm. I'm under the impression there's a race condition within the Makefile.
I git grep'd to find if a similar case existed in the code base, but I didn't manage to find any. Then, here's another proposal, closer to what already exist in the current Makefile.
There was a problem hiding this comment.
This check will probably need to be guarded based on platform as well. I do agree that objdump would probably be the best way to go here, but it's probably only reliably available on Linux (and maybe some BSDs). By default it's not on OSX and I doubt it's available on Windows much.
Same with checking for --gc-sections as well, unfortunately that's only the name of the argument on Linux. On OSX it's -Wl,-dead_strip and on MSVC it's something different as well.
|
Thanks! Can you squash these commits down into one as well? |
JohanLorenzo
changed the title
|
@alexcrichton Thank you for the help and the review. Here's the squashed commit. I have a couple of questions remaining: How would it be possible to pass this flag to cargo? I looked up and saw |
|
Currently there's not a fantastic way to pass this sort of option down through Cargo to the compiler, but something like Ideally I'd like a |
|
cc @rust-lang/tools |
|
|
|
lgtm |
|
I idly wonder if this argument might be better phrased as |
|
@huonw I was thinking something similar as well, yeah. I think that anything relating to stripping dead code, however, may also be a bit of a misnomer for a few reasons:
Not that the points are really much in favor of |
|
Ok, the tools team talked about this during triage today and the conclusion was that this is a good option to have, but we likely want to not call it I'm personally kinda leaning towards "link-dead-code" as it matches what happens on OSX and MSVC (the linker just literally strips dead code) and the interpretation on Linux basically just ends up being the same thing. @JohanLorenzo what do you think? |
|
|
JohanLorenzo
changed the title
JohanLorenzo
changed the title
Turning gc-sections off improves code coverage based for tools which use DWARF debugging information (like kcov). Otherwise dead code is stripped and kcov returns a coverage percentage that doesn't reflect reality.
|
Thanks @JohanLorenzo! |
|
⌛ Testing commit 274f27a with merge c01baae... |
|
💔 Test failed - auto-mac-64-opt |
|
@bors: retry On Thu, Feb 11, 2016 at 2:18 PM, bors notifications@github.com wrote:
|
|
⌛ Testing commit 274f27a with merge d561382... |
|
💔 Test failed - auto-mac-64-nopt-t |
|
@bors: retry On Thu, Feb 11, 2016 at 8:14 PM, bors notifications@github.com wrote:
|
|
@bors: force |
|
@bors: retry |
1 similar comment
|
@bors: retry |
…richton Tools which rely on DWARF for generating code coverage report, don't generate accurate numbers on test builds. For instance, [this sample main](https://github.com/JohanLorenzo/rust-testing-example/blob/757bdbf3887f43db9771c20cb72dfc32aa8f4321/src/main.rs) returns [100% coverage](https://coveralls.io/builds/4940156/source?filename=main.rs) when [kcov](https://github.com/SimonKagstrom/kcov/) runs. With @pnkfelix 's great help, we could narrow down the issue: The linker strips unused function during phase 6. Here's a patch which stops stripping when someone calls `rustc --test $ARGS`. @pnkfelix wasn't sure if we should add a new flag, or just use --test. What do you think @alexcrichton ? Also, I'm not too sure: where is the best place to add a test for this addition? Thanks for the help!
|
💔 Test failed - auto-mac-64-opt |
|
@bors: retry On Thu, Feb 11, 2016 at 11:04 PM, bors notifications@github.com wrote:
|
|
⚡ Previous build results for auto-linux-64-nopt-t, auto-linux-cross-opt, auto-mac-ios-opt are reusable. Rebuilding only auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-64-debug-opt, auto-linux-64-opt, auto-linux-64-x-android-t, auto-linux-musl-64-opt, auto-mac-32-opt, auto-mac-64-nopt-t, auto-mac-64-opt, auto-win-gnu-32-nopt-t, auto-win-gnu-32-opt, auto-win-gnu-64-nopt-t, auto-win-gnu-64-opt, auto-win-msvc-32-opt, auto-win-msvc-64-opt... |
|
Yay ⭐ |
| @@ -507,6 +507,8 @@ options! {CodegenOptions, CodegenSetter, basic_codegen_options, | |||
| "system linker to link outputs with"), | |||
| link_args: Option<Vec<String>> = (None, parse_opt_list, | |||
| "extra arguments to pass to the linker (space separated)"), | |||
| link_dead_code: bool = (false, parse_bool, | |||
| "let the linker strip dead coded (turning it on can be used for code coverage)"), | |||
There was a problem hiding this comment.
this description is not right, seems it should be "let the linker link dead code" or simply "link dead code"
Update docs for `-Clink-dead-code` to discourage its use The `-Clink-dead-code` flag was originally added way back in rust-lang#31368, apparently to help improve the output of some older forms of code coverage measurement, and also to address some use-cases for wanting to suppress linker flags like `-dead_strip` and `--gc-section`. In the past it might have also been useful in conjunction with `-Cinstrument-coverage`, but subsequent improvements to coverage instrumentation have made it unnecessary there. [It is also currently used by cargo-fuzz by default](rust-fuzz/cargo-fuzz#391), for reasons that are possibly no longer relevant. --- The flag currently does more than its name suggests, affecting not just linker flags, but also monomorphization decisions. It has also contributed to ICEs (e.g. rust-lang#135515) that would not have occurred without link-dead-code. --- For now, this PR just updates the documentation to be more realistic about what the flag does, and when it should be used (approximately never). In the future, it might be worth looking into properly deprecating this flag, and perhaps making it a no-op if feasible.
Rollup merge of rust-lang#135561 - Zalathar:link-dead-code, r=saethlin Update docs for `-Clink-dead-code` to discourage its use The `-Clink-dead-code` flag was originally added way back in rust-lang#31368, apparently to help improve the output of some older forms of code coverage measurement, and also to address some use-cases for wanting to suppress linker flags like `-dead_strip` and `--gc-section`. In the past it might have also been useful in conjunction with `-Cinstrument-coverage`, but subsequent improvements to coverage instrumentation have made it unnecessary there. [It is also currently used by cargo-fuzz by default](rust-fuzz/cargo-fuzz#391), for reasons that are possibly no longer relevant. --- The flag currently does more than its name suggests, affecting not just linker flags, but also monomorphization decisions. It has also contributed to ICEs (e.g. rust-lang#135515) that would not have occurred without link-dead-code. --- For now, this PR just updates the documentation to be more realistic about what the flag does, and when it should be used (approximately never). In the future, it might be worth looking into properly deprecating this flag, and perhaps making it a no-op if feasible.
Tools which rely on DWARF for generating code coverage report, don't generate accurate numbers on test builds. For instance, this sample main returns 100% coverage when kcov runs.
With @pnkfelix 's great help, we could narrow down the issue: The linker strips unused function during phase 6. Here's a patch which stops stripping when someone calls
rustc --test $ARGS. @pnkfelix wasn't sure if we should add a new flag, or just use --test. What do you think @alexcrichton ?Also, I'm not too sure: where is the best place to add a test for this addition?
Thanks for the help!