Thanks for this great repo!

Just wanted to point out that in the strip Symbols from Binary section, it mentions nightly 1.45.0, however, this is now a stable version.

In addition to panic_immediate_abort it should use !#[no_main] and avoid println!.

This allows actually excluding formatting code while also using some of libstd's features.

I created a custom ld script that makes elf64 binary smaller. It is possible to add this script to build sequence by creating build.rs file:

fn main() {
	println!("cargo:rustc-link-arg=-Wl,-T,elf64-min.ld");
}

Here is elf64-min.ld:

OUTPUT_FORMAT("elf64-x86-64")
ENTRY(_start)
PHDRS {
	text PT_LOAD FILEHDR PHDRS;
	/*tls PT_TLS;*/ /* uncomment this if you use std or pthreads */
	interp PT_INTERP;
	dynamic PT_DYNAMIC;
}

SECTIONS
{
	. = SIZEOF_HEADERS;
	t : {
		KEEP (*(.init))
		*(.text*)
		KEEP (*(.fini))
		*(.rodata*)
		*(.data*)
		*(.bss*)
	} :text
	.init_array : {
		PROVIDE_HIDDEN (__init_array_start = .);
		KEEP (*(SORT_BY_INIT_PRIORITY(.init_array*)))
		PROVIDE_HIDDEN (__init_array_end = .);
	} :text
	.rel : { *(.data.rel*) } :text

	td : { *(.tdata*) } :text :tls
	tb : { *(.tbss*) } :text :tls

	i : {
		*(.interp)
	} :text :interp

	d : {
		*(.dynamic)
		*(.got)
		*(.got.*)
		*(.gnu.*)
		*(.dynsym)
	} :dynamic :text

	/DISCARD/ : { *(.note*) }
}

Consider adding cargo-binutils to the README. It provides easy to use cargo commands for a few llvm tools that can be installed via rustup. These tools work for quite a few platforms including windows and is easy to get setup if you use rustup for your rust toolchain.

$ rustup component add llvm-tools-preview
$ cargo install cargo-binutils
$ cargo strip

The cargo-binutils cargo commands automatically handle building the project if needed as well as finding and passing the target binary path to the tool. They also support the majority of the command line options that cargo build does to make the tools as intuitive as using cargo itself.

Also provides access to llvm-size via cargo size.

https://github.com/rust-embedded/cargo-binutils

Disclaimer: I recently did a little bit of work on cargo-binutils to make it easier to use and more closely match the built in cargo commands, and the README is a little out of date because of that.

It might be useful to have a [profile.dev] section which has matching panic behavior for the xargo build (unless the idea was to demonstrate both kinds of panic).

Enables strip in the example Cargo.toml files in this repository, per the recommendation now in README after #34.

The reminder to strip has been removed from the README, since the examples will now do that automatically.

Running $ cargo +nightly build -Z strip=symbols on Windows I get this error message:

error: unknown `-Z` flag specified: strip

I just updated my nightly toolchain still the same error. Any idea what this may be happening?

For the sake of completeness, it'd probably be a good idea to mention the sstrip utility from ELFkickers.

As this mirror explains:

Most ELF executables are built with both a program header table and a section header table. However, only the former is required in order for the OS to load, link and execute a program. sstrip attempts to extract the ELF header, the program header table, and its contents, leaving everything else in the bit bucket. It can only remove parts of the file that occur at the end, after the parts to be saved. However, this almost always includes the section header table, along with a few other sections that are not involved in program loading and execution.

It should be noted that most programs that work with ELF files are dependent on the section header table as an index to the file's contents. Thus, utilities such as gdb and objdump will often have limited functionality when working with an executable with no section header table. Some other utilities may refuse to work with them at all.

Basically, it's a tool primarily used for things like saving flash memory on embedded Linux devices which will shave a few more bytes off what the regular strip utility produces.

I read both:

• https://doc.rust-lang.org/cargo/reference/profiles.html#opt-level
• https://github.com/johnthagen/min-sized-rust#optimize-for-size

What I don't understand is which speed gain I'm changing if I use:

[profile.release]
opt-level = "z"

instead of:

[profile.release]
opt-level = 3

• Is it right that today opt-level = 3 is the best setting (for opt-level section) for runtime speed?

• If I instead use opt-level = "z" I'm decreasing runtime performance, right?

I'm not interested in building/compiling speed.

Thanks a lot for this repository. It contains a lot of useful information. I found that stripping cargo generated binaries is a bit painful as you need to identify their names manually.

To simplify the process, I released cargo-strip over the week-end that automates this. It could be improved but works fine for my needs.

It is possible to cross compile w/ the +nightly targets.

ex.

rustup +nightly target add x86_64-unknown-linux-musl
cargo +nightly build -Z build-std=std,panic_abort -Z build-std-features=panic_immediate_abort \
    --target x86_64-unknown-linux-musl --release

Will work, this can be added as an addendum to the Optimize libstd and Remove Panic String sections.

Discovered from: https://github.com/rust-lang/wg-cargo-std-aware/issues/76

Since Rust can't do polymorphization properly yet, using generics generates a lot of duplicated functions because of monomorphization. These functions take space in the binary, even though they have completely the same instructions.

Some linkers (gold, lld) can deduplicate these identical functions using Identical Code Folding, and thus reduce binary size (and potentially also improve usage of the i-cache).

You can specify this linker option using a linker flag, for example like this:

$ RUSTFLAGS="-Clink-args=-fuse-ld=lld -Clink-args=-Wl,--icf=all" cargo build

I measured the binary size change for the following program:

fn foo() {
    let mut a: Vec<u8> = vec![1, 2, 3];
    a.pop();

    let mut b: Vec<u32> = vec![1, 2, 3];
    b.pop();

    let mut c: Vec<i32> = vec![1, 2, 3];
    c.pop();
}

fn main() {
    foo();
}

Here are binary sizes are after running strip on them:

| Linker | Mode | Binary size (B) | ICF (Identical Code Folding) | |--------|---------|-----------------|------------------------------| | gold | debug | 342696 | No | | gold | debug | 330408 | Yes | | gold | release | 322216 | No | | gold | release | 318120 | Yes | | lld | debug | 330968 | No | | lld | debug | 321840 | Yes | | lld | release | 310616 | No | | lld | release | 306848 | Yes |

Generics with static dispatch can lead to duplicated functions, and if they are big enough, it will make for a large piece of the final binary.

Alternatives are dynamic dispatch with dyn, or just removing generic code.

Is seems very important for minimizing binary size.

(If you don't want to change the function API, and the function is being generic over something like AsRef<Path>, you can also create helper function which resolves path.as_ref() and calls a non-generic function that receives &Path instead.)

When https://github.com/rust-lang/rfcs/pull/2480 is stabilized and implemented, it should be possible to create binaries that don't depend on std but do depend on alloc. This would be a step between no_std and no_main, because at least you could use the heap. The actual sample hello world code would probably not change much. It would probably be best to show off using a Vec in this instance.

This could probably be added now as a nightly subproject.