Building without unwinding support

[yshui]

Problem

So I am trying to make sure the code I build never unwinds. I am doing:

# Cargo.toml
[profile.release]
panic = "abort"

# .cargo/config.toml
[unstable]
build-std = ["std", "panic_abort"]
build-std-features = ["panic_immediate_abort"]

Yet cargo still builds and links panic_unwind, which in turn links unwind, and as a consequence links libgcc_s.so. Related to rust-lang/rust#82521, which is trying to solve the missing libgcc_s problem. Here we don't want to link any unwind library at all.

Steps

No response

Possible Solution(s)

No response

Notes

Did a quick code search here, so this may be wrong.

cargo/src/cargo/core/compiler/standard_lib.rs

Lines 26 to 30 in f651497

	crates.insert("core");
	crates.insert("alloc");
	crates.insert("proc_macro");
	crates.insert("panic_unwind");
	crates.insert("compiler_builtins");

But it looks like cargo blindly adds panic_unwind to the list of libraries, whether it's needed or not.

Version

[yshui]

I was wrong about why panic_unwind is pulled in. Now I don't understand why it is.

And also std::backtrace uses libunwind independent of panic_immediate_abort, it should probably switch to noop if that feature is enabled.

Currently I am working around this with a horrible hack, replacing panic_unwind with an empty crate and patching std, and point cargo to them with __CARGO_TESTS_ONLY_SRC_ROOT

[weihanglo]

Do you have a step-by-step reproducible example?

Anyhow, it happens to be this tracking issue rust-lang/wg-cargo-std-aware#29.

[weihanglo]

Going to close this in favor of rust-lang/wg-cargo-std-aware#29. Let us know if this should remain open for any reason.

[yshui]

@weihanglo hi, i phrased this issue around panic strategies, but later i realized what really matters is the use of the unwind crate, (i.e. how to build on a toolchain without an unwind library?), which is not limited to just panic strategies since it is also used by std::backtrace. i can rephrase the issue, can you reopen it?

[weihanglo]

@yshui Can definitely reopen this as a tracking issue, though I am not sure what difference it would make.
As I understand it so far, this unwinding issue can only be resolved when we figure out rust-lang/wg-cargo-std-aware#29. And that issue did talk about the unconditional "panic_unwind" activation problem. I feel like similar discussions are better happening in one place rather separate. What would you want to see from keeping this open?

[yshui]

yes there is some overlap, but i think rust-lang/wg-cargo-std-aware#29 is a prerequisite of this issue. yes, the panic_unwind problem must be resolved first, with that resolved, we still need to figure out std::backtrace etc.

another option i think would be expand wg#29 to include all uses of unwind, instead of just panic strategies; and one more option would be limit this issue to be only about std::backtrace

[weihanglo]

Thanks for the clarification!

However, I still don't fully understand what you're looking for. Do you specifically ask for std::backtrace support without depending on unwinder from gcc when panic=abort?

Haven't tried but by reading the doc of backtrace I think you can specify -Cforce-unwind-tables=yes when panic=abort, or activate the llvm-libunwind std feature. For musl it'll force link to in-tree LLVM unwinder. These options above seem configurable at this moment. Just some scenarios are blocked on panic-unwind enabling. And if you don't even want to link to LLVM libunwind like you've mentioned in #15146 (comment), there is nothing Cargo or -Zbuild-std can do for that. Please file a ticket to rust-lang/rust.

we still need to figure out std::backtrace etc.

Therefore, I wonder what needs to be figured out here. Feel like we are kinda pivoting the issue from “don't pass down panic-unwind” to something else?

[weihanglo]

FWIW, here is the backtrace support issue: rust-lang/wg-cargo-std-aware#16.

[yshui]

However, I still don't fully understand what you're looking for.

What I am looking for is building Rust programs without any unwinder at all. Currently, this means two things (IIUC): 1. use panic=abort for all dependencies, and don't build panic_unwind. 2. use the noop backtrace implementation.

wg#29 only concerns the first point, and I think no one is tracking (2)? Hopefully this makes it clear.

And I think you are right that this probably belongs to rust-lang/rust instead of here. So I think what needs to happen is a std feature for choosing the noop backtrace, which I can then use with -Zbuild-std-features.

[weihanglo]

Thanks. So we already have two issues tracking them:

• Support different panic strategies. wg-cargo-std-aware#29 for the first one
• Deps: backtrace wg-cargo-std-aware#16 kinda for the second one. To make backtrace, I am not sure if the current std could achieve that. You either need to bootstrap std to try it out different build combination, or ask in rust-lang/backtrace-rs if it is possible. x86_64-unknown-linux-musl with -Ctarget-feature=-crt-static links to glibc rust#135244 has some information but it seems to be only partially related.

Since this is kinda blocked on externals projects, and we have two issues tracking them already, I am going to close this. Thanks for help clarify the current situation!