rust-lang / rust

Empowering everyone to build reliable and efficient software.
https://www.rust-lang.org
Other
98.33k stars 12.72k forks source link

Move metadata out of dylibs #23366

Open vadimcn opened 9 years ago

vadimcn commented 9 years ago

Crate metadata constitute a significant proportion of Rust dylibs. It's only needed for compilation; otherwise it just bloats up the size of Rust programs, and, unlike debug info, can't even be easily stripped. In the case of dylibs, we could move metadata out into a companion file (say, <library>.rsmd), which developers may choose to not distribute if linking to the library is not expected (for example, Rust's own stage0 binaries). I think this approach would be very congruent with Rust's philosophy of zero cost abstractions. The only downside I can see, is that distribution of dylibs as libraries would become slightly less convenient as there would be two files instead of one.

nagisa commented 9 years ago

Is is actually pretty easy to strip them. The incantation is something similar to strip -R __note.rustc for apples and strip -R .note.rustc for everything else.

vadimcn commented 9 years ago

Is is actually pretty easy to strip them.

Ah, that's nice to know!
Still, one has to jump through extra hoops to get the optimal binary. This seems... sub-optimal. People are already asking why Rust executables are so much bigger than C++'s. Soon they'll notice that dylibs are larger too.

steveklabnik commented 8 years ago

Triage: no change, marking with enhancement, since it can be stripped.

jonas-schievink commented 8 years ago

Don't cdylibs solve this?

retep998 commented 8 years ago

cdylib does solve this issue for itself, however the issue still exists for dylib for people who really want to have their Rust program depends on Rust dylibs instead of statically linking them. Also this has an impact on the size of Rust distributions, since rustc's dependencies are all in dylib form (so plugins can work correctly), while in reality they don't need any of that metadata bloat since code is compiled against the libraries in the appropriate rustlib folder.

cuviper commented 8 years ago

Note that it's not actually easy to strip these notes according to #26764.

Another fun aspect is that systems which use .gnu_debugdata, described here, will end up duplicating the entire .note.rustc. The given procedure uses objcopy --only-keep-debug, which also preserves notes, then further strips into a mini_debuginfo file with just symbol tables and those notes. That mini_debuginfo finally gets compressed into a new .gnu_debugdata section on the original file. But it's not so "mini" when it contains all of .note.rustc.

That MiniDebuginfo procedure can probably add an exclusion, the same as it does for .gdb_index and .comment already, but it wouldn't be nice if every language had their own special exclusions here...

cuviper commented 8 years ago

Now that #35409's 1bb14445160329c2ca5ff9c202e791ca0098d944 converted it away from an allocated note, it should be fine to be stripped.

steveklabnik commented 7 years ago

Triage: not aware of any work on this issue.

gilescope commented 4 years ago

Now that we have cargo strip can we close this?

bjorn3 commented 2 years ago

https://github.com/rust-lang/rust/pull/93945 once I revive it would fix this issue.