Tracking issue for -Z strip=val option

[petrochenkov]

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:

• The option was introduced in add codegen option strip #71825.
• Documentation is added in rustc-book: Document -Z strip=val option #72111.

[ccope]

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

[ehuss]

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

[ehuss]

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]

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.

[eggyal]

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?

[eggyal]

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]

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]

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]

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

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

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

[calavera]

what are the next steps now that #82037 has been merged @joshtriplett? is there anything else I can help with?

[joshtriplett]

Given that #82037 just got merged, the next step would be to encourage people to test it in nightly, and provide some experience reports. Support for other targets appears to be ready, but we shouldn't stabilize this right after we add brand new support for macOS. Once we have some experience reports confirming that it works well for people, the next steps after that would be a stabilization report and stabilization PR for -Z strip=val, and then a stabilization PR for cargo's strip profile option.

[zizhengtai]

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

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

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]

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]

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]

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

[joshtriplett]

Submitted #88137 to try to address this.

[joshtriplett]

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]

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

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

[joshtriplett]

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

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]

Stabilization PR at #90058

[joshtriplett]

#90058 has been merged!

[guytbk]

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

[tanriol]

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

[ajeetdsouza]

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

[Wyvern]

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]

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