Add additional build target which optimizes for size

[gladiac]

OpenWRT (https://openwrt.org) is a project which builds and distributes firmware for embedded devies like routers, access points, and so on. These devices are usually very limited in terms of storage. Therefore, optimizing binaries for size at the cost of execution speed is usually desired. As I intend to provide a vaultwarden package for OpenWRT this change would help significantly.

This PR adds an additional build-target, namely "release-micro", which implements several parameters which optimize in favor of binary size.

The following parameters were chosen:

• opt-level "z": Optimize for size with disabled loop vectorization
• strip "symbols": Strip debuginfo and symbols from binary
• lto "fat": Enable link-time optimizations across all crates
• codegen-units 1: Disable parallelization of code generation to allow for additional optimizations
• panic "abort": Abort on Panic() instead of unwinding

All these build parameters significantly reduce the binary size from >40MB to <15MB - the actual amount depends on the target architecture.

I would like to upstream this new build target to keep our build environment simple. Other projects which deploy vaultwarden on size-constrained environments may benefit from this change too.

[williamdes]

💯

[dani-garcia]

Yeah, this seems pretty reasonable

Side note: @BlackDex Now that our CI time is not that bad, would it be worth it to enable fat LTO and 1 codegen units on the normal release profile as well?

[BlackDex]

Yeah, this seems pretty reasonable

Side note: @BlackDex Now that our CI time is not that bad, would it be worth it to enable fat LTO and 1 codegen units on the normal release profile as well?

I still want to add some caching which might improve the build time even more.
Also, the upcoming parallel front-end feature might help there too.

And, we might want to switch to v1.74.0 as well which might also help.

I can trigger some builds on my fork using fat and 1 codegen.

Also, I'm not sure what will happen with code build using this PR's settings and the backtrace catching part.
We might want to either disable that if we can some how see debug symbols are stripped or panic is set to abort, since then the backtrace code doesn't apply at all.

[gladiac]

Yeah, this seems pretty reasonable
Side note: @BlackDex Now that our CI time is not that bad, would it be worth it to enable fat LTO and 1 codegen units on the normal release profile as well?

I still want to add some caching which might improve the build time even more. Also, the upcoming parallel front-end feature might help there too.

And, we might want to switch to v1.74.0 as well which might also help.

I can trigger some builds on my fork using fat and 1 codegen.

Also, I'm not sure what will happen with code build using this PR's settings and the backtrace catching part. We might want to either disable that if we can some how see debug symbols are stripped or panic is set to abort, since then the backtrace code doesn't apply at all.

I am really not an expert on this matter but regarding the backtrace functionality - without symbols the backtraces will still work but without the symbol names because they are not available. I just tried it.

Full Backtrace with symbols:

gladiac@cosmos:/tmp/a/hello$ RUST_BACKTRACE=full ./target/release/hello 
thread 'main' panicked at src/main.rs:7:3:
hello
stack backtrace:
   0:     0x558eaf2ea71c - std::backtrace_rs::backtrace::libunwind::trace::he43a6a3949163f8c
                               at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/std/src/../../backtrace/src/backtrace/libunwind.rs:93:5
   1:     0x558eaf2ea71c - std::backtrace_rs::backtrace::trace_unsynchronized::h50db52ca99f692e7
                               at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
   2:     0x558eaf2ea71c - std::sys_common::backtrace::_print_fmt::hd37d595f2ceb2d3c
                               at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/std/src/sys_common/backtrace.rs:67:5
   3:     0x558eaf2ea71c - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h678bbcf9da6d7d75
                               at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/std/src/sys_common/backtrace.rs:44:22
   4:     0x558eaf30a20c - core::fmt::rt::Argument::fmt::h3a159adc080a6fc9
                               at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/core/src/fmt/rt.rs:138:9
   5:     0x558eaf30a20c - core::fmt::write::hb8eaf5a8e45a738e
                               at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/core/src/fmt/mod.rs:1094:21
   6:     0x558eaf2e848e - std::io::Write::write_fmt::h9663fe36b2ee08f9
                               at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/std/src/io/mod.rs:1714:15
   7:     0x558eaf2ea504 - std::sys_common::backtrace::_print::hcd4834796ee88ad2
                               at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/std/src/sys_common/backtrace.rs:47:5
   8:     0x558eaf2ea504 - std::sys_common::backtrace::print::h1360e9450e4f922a
                               at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/std/src/sys_common/backtrace.rs:34:9
   9:     0x558eaf2ebac3 - std::panicking::default_hook::{{closure}}::h2609fa95cd5ab1f4
                               at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/std/src/panicking.rs:270:22
  10:     0x558eaf2eb7dc - std::panicking::default_hook::h6d75f5747cab6e8d
                               at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/std/src/panicking.rs:290:9
  11:     0x558eaf2ec049 - std::panicking::rust_panic_with_hook::h57e78470c47c84de
                               at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/std/src/panicking.rs:707:13
  12:     0x558eaf2ebf01 - std::panicking::begin_panic_handler::{{closure}}::h3dfd2453cf356ecb
                               at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/std/src/panicking.rs:597:13
  13:     0x558eaf2eac46 - std::sys_common::backtrace::__rust_end_short_backtrace::hdb177d43678e4d7e
                               at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/std/src/sys_common/backtrace.rs:170:18
  14:     0x558eaf2ebc92 - rust_begin_unwind
                               at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/std/src/panicking.rs:595:5
  15:     0x558eaf2ced83 - core::panicking::panic_fmt::hd1e971d8d7c78e0e
                               at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/core/src/panicking.rs:67:14
  16:     0x558eaf2cf4df - hello::foo::hd5bda17c75105785
  17:     0x558eaf2cf496 - hello::main::h822af7a1e966b274
  18:     0x558eaf2cf453 - std::sys_common::backtrace::__rust_begin_short_backtrace::h2b9458e8cd1b05b5
  19:     0x558eaf2cf469 - std::rt::lang_start::{{closure}}::h1c0a953e0c39fa29
  20:     0x558eaf2e66cb - core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once::hbcc4f8a3f5ada78c
                               at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/core/src/ops/function.rs:284:13
  21:     0x558eaf2e66cb - std::panicking::try::do_call::he5f117a9e13dadde
                               at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/std/src/panicking.rs:502:40
  22:     0x558eaf2e66cb - std::panicking::try::h2f3af9afce3a0443
                               at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/std/src/panicking.rs:466:19
  23:     0x558eaf2e66cb - std::panic::catch_unwind::h6d6c387f38ef05ea
                               at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/std/src/panic.rs:142:14
  24:     0x558eaf2e66cb - std::rt::lang_start_internal::{{closure}}::h6ca09d5905711415
                               at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/std/src/rt.rs:148:48
  25:     0x558eaf2e66cb - std::panicking::try::do_call::ha9fd18ea06654a4b
                               at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/std/src/panicking.rs:502:40
  26:     0x558eaf2e66cb - std::panicking::try::hda5c2a4432362341
                               at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/std/src/panicking.rs:466:19
  27:     0x558eaf2e66cb - std::panic::catch_unwind::h440f731b142bc235
                               at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/std/src/panic.rs:142:14
  28:     0x558eaf2e66cb - std::rt::lang_start_internal::hc0b4e50f058f62ce
                               at /rustc/cc66ad468955717ab92600c770da8c1601a4ff33/library/std/src/rt.rs:148:20
  29:     0x558eaf2cf515 - main
  30:     0x7fdcd30d96ca - <unknown>
  31:     0x7fdcd30d9785 - __libc_start_main
  32:     0x558eaf2cf381 - _start
  33:                0x0 - <unknown>

And this is what it looks like with the symbols stripped:

gladiac@cosmos:/tmp/a/hello$ RUST_BACKTRACE=full ./target/strip/hello 
thread 'main' panicked at src/main.rs:7:3:
hello
stack backtrace:
   0:     0x55999557471c - <unknown>
   1:     0x55999559420c - <unknown>
   2:     0x55999557248e - <unknown>
   3:     0x559995574504 - <unknown>
   4:     0x559995575ac3 - <unknown>
   5:     0x5599955757dc - <unknown>
   6:     0x559995576049 - <unknown>
   7:     0x559995575f01 - <unknown>
   8:     0x559995574c46 - <unknown>
   9:     0x559995575c92 - <unknown>
  10:     0x559995558d83 - <unknown>
  11:     0x5599955594df - <unknown>
  12:     0x559995559496 - <unknown>
  13:     0x559995559453 - <unknown>
  14:     0x559995559469 - <unknown>
  15:     0x5599955706cb - <unknown>
  16:     0x559995559515 - <unknown>
  17:     0x7f1fe04766ca - <unknown>
  18:     0x7f1fe0476785 - __libc_start_main
  19:     0x559995559381 - <unknown>
  20:                0x0 - <unknown>

To reproduce, I just created a plain new rust project and built with the followin main.rs:

fn main() {
  foo();
}

#[inline(never)]
fn foo() {
  panic!("hello");
}

Then I made a build with standard release parameters and one with additional symbol stripping.

[BlackDex]

While it is a choice to strip the symbols or not. It might be better for viewing and the logs to not print the backtrace in those cases.
Shouldn't be that hard.

[gladiac]

While it is a choice to strip the symbols or not. It might be better for viewing and the logs to not print the backtrace in those cases. Shouldn't be that hard.

I guess you are right. It probably makes sense to just not print the backtrace if the debug symbols are missing. The memory locations alone are probably not very helpful to analyze a potential panic situation.

Do you want this to be implemented as part of this PR? Because I am a novice at rust and do not know the vaultwarden codebase so it would take a while until I can provide the necessary changes.

[BlackDex]

While it is a choice to strip the symbols or not. It might be better for viewing and the logs to not print the backtrace in those cases. Shouldn't be that hard.

I guess you are right. It probably makes sense to just not print the backtrace if the debug symbols are missing. The memory locations alone are probably not very helpful to analyze a potential panic situation.

Do you want this to be implemented as part of this PR? Because I am a novice at rust and do not know the vaultwarden codebase so it would take a while until I can provide the necessary changes.

No, i think that is out of scope for this. Other people could also strip the binary or even some other build processes.