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

Tracking issue for -Z strip=val option #72110

Closed
petrochenkov opened this issue May 11, 2020 · 39 comments
Closed

Tracking issue for -Z strip=val option #72110

petrochenkov opened this issue May 11, 2020 · 39 comments
Labels
B-unstable Blocker: Implemented in the nightly compiler and unstable. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@petrochenkov
Copy link
Contributor

petrochenkov commented May 11, 2020

Option -Z strip=val controls stripping of debuginfo and similar auxiliary data from binaries
during linking.

Supported values for this option are:

  • none - debuginfo and symbols (if they exist) are copied to the produced binary or separate files
    depending on the target (e.g. .pdb files in case of MSVC).
  • debuginfo - debuginfo sections and debuginfo symbols from the symbol table section
    are stripped at link time and are not copied to the produced binary or separate files.
  • symbols - same as debuginfo, but the rest of the symbol table section is stripped as well
    if the linker supports it.

History:

@jonas-schievink jonas-schievink added B-unstable Blocker: Implemented in the nightly compiler and unstable. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels May 11, 2020
Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this issue May 20, 2020
RalfJung added a commit to RalfJung/rust that referenced this issue May 21, 2020
RalfJung added a commit to RalfJung/rust that referenced this issue May 21, 2020
@ccope
Copy link

ccope commented Jun 1, 2020

Is there a way to make the compiler emit separate debug symbol files (besides the default on Windows)?

@ehuss
Copy link
Contributor

ehuss commented Jun 1, 2020

@ccope I think split debug support on Linux is tracked in #34651.

@ehuss
Copy link
Contributor

ehuss commented Jun 1, 2020

This flag doesn't seem to work with the Darwin linker (ld64). MacOS is defined to use the gcc linker flavor, but although it uses clang, the underlying ld64 doesn't support gcc options.

Is there an intent to support that?

@petrochenkov
Copy link
Contributor Author

src\librustc_codegen_ssa\back\linker.rs has a bunch of special cases for the MacOS linker, but it's still considered a GccLinker linker flavor.
Perhaps it needs one more such case for symbol stripping.

That's pretty much all I know about MacOS linker and MacOS in general, so no plans to fix it from me.

bors added a commit to rust-lang/cargo that referenced this issue Jun 1, 2020
Disable strip_works test on macos.

This feature doesn't work on macOS, because it uses ld64 with clang.  See rust-lang/rust#72110 (comment).
@eggyal
Copy link
Contributor

eggyal commented Jun 8, 2020

MacOS linker supports -s and -S shorthand arguments, but not --strip-all and --strip-debug longhand arguments; given that the shorthands are supported by all GCC linkers (afaik), perhaps one only needs to change GccLinker::debuginfo() to use those instead?

Dylan-DPC-zz pushed a commit to Dylan-DPC-zz/rust that referenced this issue Jun 8, 2020
…henkov

Use shorthand linker strip arguments in order to support MacOS

Per discussion from rust-lang#72110 (comment) onward, the current `-Z strip` options aren't supported by the MacOS linker, but I think only because it doesn't support the longhand arguments `--strip-debug` and `--strip-all`.

This PR switches to using the shorthand arguments `-s` and `-S` instead, which (I believe) are supported by all GCC linkers.
@eggyal
Copy link
Contributor

eggyal commented Jun 9, 2020

It turns out that, whilst the MacOS linker accepts the -s and -S shorthand arguments, they are obsolete and ignored (they generate warnings rather than the fatal errors produced with the longhand arguments).

The MacOS linker no longer provides any ability to strip its output. Instead, Apple provide a strip utility that can be run on a resulting binary—but caveat that it is designed for the output from Apple compilers and may not work with the layouts produced by other compilers. I've not had any issues using it with rust binaries, however.

@AlexApps99
Copy link
Contributor

This option needs to accept true and false, where true would be the equivalent of symbols and false to none.
Currently both lto and debug also support configuration using true for the highest level, and false for disabled.

Including this option would make a lot of sense and simplify usage of it (but would not remove the old functionality either)

@morr0ne
Copy link
Contributor

morr0ne commented Jan 1, 2021

What's the blocker on this? I've been using this option for months without noticing any problem, is someone actively looking into it or this just sitting here?

@calavera
Copy link
Contributor

calavera commented Feb 8, 2021

@morr0ne for what I can tell, this option doesn't work on MacOS yet, as expressed in the comment above:

It turns out that, whilst the MacOS linker accepts the -s and -S shorthand arguments, they are obsolete and ignored (they generate warnings rather than the fatal errors produced with the longhand arguments).

The MacOS linker no longer provides any ability to strip its output. Instead, Apple provide a strip utility that can be run on a resulting binary—but caveat that it is designed for the output from Apple compilers and may not work with the layouts produced by other compilers. I've not had any issues using it with rust binaries, however.

#72110 (comment)

@calavera
Copy link
Contributor

@AlexApps99 that just landed in cargo's main branch:

This option needs to accept true and false, where true would be the equivalent of symbols and false to none.
Currently both lto and debug also support configuration using true for the highest level, and false for disabled.

rust-lang/cargo@ab64d13

@oysterpack
Copy link

When do we expect this to be released onto stable rust?

@zizhengtai
Copy link

zizhengtai commented Aug 15, 2021

$ cargo --version
cargo 1.56.0-nightly (b51439fd8 2021-08-09)

It seems even with strip = "symbols", cargo still produces larger binaries compared to those processed by the strip command, at least on macOS. For example, I created a stub project with cargo new hello, and enabled stripping in Cargo.toml:

cargo-features = ["strip"]

[package]
name = "hello"
version = "0.1.0"
edition = "2018"

[profile.release]
strip = "symbols"

And then:

$ cargo build --release
$ du target/release/hello
576	target/release/hello
$ strip target/release/hello
$ du target/release/hello
544	target/release/hello

Also, without modifying the generated Cargo.toml, the strip command results in the same final size:

$ cargo build --release
$ du target/release/hello
824	target/release/hello
$ strip target/release/hello
$ du target/release/hello
544	target/release/hello

So hopefully cargo can produce binaries as small as what strip produces, otherwise it would defeat the purpose since we'd have to run strip again anyway to get the smallest possible binaries.

@zizhengtai
Copy link

$ cargo --version
cargo 1.56.0-nightly (b51439fd8 2021-08-09)

It seems even with strip = "symbols", cargo still produces larger binaries compared to those processed by the strip command, at least on macOS. For example, I created a stub project with cargo new hello, and enabled stripping in Cargo.toml:

cargo-features = ["strip"]

[package]
name = "hello"
version = "0.1.0"
edition = "2018"

[profile.release]
strip = "symbols"

And then:

$ cargo build --release
$ du target/release/hello
576	target/release/hello
$ strip target/release/hello
$ du target/release/hello
544	target/release/hello

Also, without modifying the generated Cargo.toml, the strip command results in the same final size:

$ cargo build --release
$ du target/release/hello
824	target/release/hello
$ strip target/release/hello
$ du target/release/hello
544	target/release/hello

So hopefully cargo can produce binaries as small as what strip produces, otherwise it would defeat the purpose since we'd have to run strip again anyway to get the smallest possible binaries.

Just realized this is because cargo uses strip -x under the hood with strip = "symbols" set. What's the reason we are doing this instead of simply strip?

@philipc
Copy link
Contributor

philipc commented Aug 15, 2021

Just realized this is because cargo uses strip -x under the hood with strip = "symbols" set. What's the reason we are doing this instead of simply strip?

It's not using strip -x, it's using linker options (strip = "debuginfo" uses --strip-debug, and strip = "symbols" uses --strip-all).

@zizhengtai
Copy link

Just realized this is because cargo uses strip -x under the hood with strip = "symbols" set. What's the reason we are doing this instead of simply strip?

It's not using strip -x, it's using linker options (strip = "debuginfo" uses --strip-debug, and strip = "symbols" uses --strip-all).

Not on macOS? calavera@df0fc6d

@zizhengtai
Copy link

Also checked that on Ubuntu, cargo produces the same sizes of binaries as strip --strip-all, but on macOS it uses strip -x and produces larger binaries.

@joshtriplett
Copy link
Member

@zizhengtai That does seem inconsistent. I think we want to use the same behavior as strip when we're given "symbols".

@joshtriplett
Copy link
Member

Submitted #88137 to try to address this.

@joshtriplett
Copy link
Member

Could someone on @rust-lang/compiler familiar with macOS review #88137 , please? I think that may be the last blocker to stabilizing strip support in rust and then in cargo.

@joshtriplett
Copy link
Member

#88137 is currently waiting on bors (thanks @michaelwoerister!); once that goes in, I'd like to propose stabilizing this option (as -C strip=val).

@Mark-Simulacrum
Copy link
Member

I think #81024 is a potential blocker, or at least, I would want to be convinced otherwise.

@joshtriplett
Copy link
Member

@Mark-Simulacrum I would like to see better support for split debug, but I don't see how an issue with split debug affects the stabilization of the strip option. I don't see any mention of the strip option in the linked issue.

@Mark-Simulacrum
Copy link
Member

Ah, I think I entirely misread somehow and thought this was about splitting as well. Yes, I agree that just stabilizing strip seems not really connected - #81024 is not a blocker then :)

Sorry!

@joshtriplett
Copy link
Member

Stabilization PR at #90058

@joshtriplett
Copy link
Member

#90058 has been merged!

@guytbk
Copy link

guytbk commented Nov 28, 2021

@joshtriplett Is there an estimation of when a new release containing this feature will be released?

@tanriol
Copy link
Contributor

tanriol commented Nov 28, 2021

Seems to be coming in 1.58 (coming to beta next week, to release in mid-January).

@ajeetdsouza
Copy link

@guytbk there's a PR to add this option to cargo too: rust-lang/cargo#10088

@Wyvern
Copy link

Wyvern commented Jan 13, 2022

Just updated rust to latest stable 1.58, but strip=true in [profile.release] still can't work as expected mentioned in pre-release notes..

What happened?

@Eh2406
Copy link
Contributor

Eh2406 commented Jan 13, 2022

As mentioned in the notes support was stabilized in rustc but not in Cargo. Cargo support will be coming in the next release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
B-unstable Blocker: Implemented in the nightly compiler and unstable. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
Status: Done
Development

No branches or pull requests