Refactor the linkage handling of libunwind

[12101111]

libunwind currently need a c/cpp library that provide _Unwind_* symbols to work. libgcc_s.so/libgcc_eh.a from gcc or libunwind.so/libunwind.a from llvm can provide those symbols.

The libunwind crate is built when compiler bootstrap, and there is a flag in config.toml that choose which implementation to use. User can't change the implementation after bootstrap ( unless build-std add a flag for this )

# Use LLVM libunwind as the implementation for Rust's unwinder.
# Accepted values are 'in-tree' (formerly true), 'system' or 'no' (formerly false).
#llvm-libunwind = 'no'

• in-tree will enable llvm-libunwind feature of libunwind
• system will enable system-llvm-libunwind feature of libunwind
• no won't enable any feature of libunwind

Ideally, the behavior of this flags would be:

• in-tree will compile the intree copy of llvm-libunwind, and link it into libunwind.rlib
• system will link the libunwind.so/libunwind.a from users' system
• no will link the libgcc_s.so/libgcc_eh.a from users' system

But the current situation is a mess:

The probems are:

• if user set target-feature=+crt-static , glibc/uclibc will always link libgcc_eh.a by libc crate, see Support static linking with glibc and target-feature=+crt-static #77386. But libunwind.a is still linked if llvm-libunwind feature is enabled:

  rust/library/unwind/src/libunwind.rs

  Lines 80 to 84 in e43c200

  	#[cfg_attr(
  	all(feature = "llvm-libunwind", any(target_os = "fuchsia", target_os = "linux")),
  	link(name = "unwind", kind = "static")
  	)]
  	extern "C" {

  This is introduced in 8d2f80b.
• musl target don't follow the llvm-libunwind feature and system-llvm-libunwind feature.
• when cc=clang, and llvm-libunwind feature is enabled, clang don't accept -std=c++11 and cause bootstrap failed, see Building rustc in Clang 9.0 error: invalid argument '-std=c++11' not allowed with 'C' #69222
• Because musl target don't follow the system-llvm-libunwind feature at all, my previous PR Don't build in-tree llvm-libunwind if system-llvm-libunwind is enable #80818 break the unwinder if set target-feature=+crt-static and enable system-llvm-libunwind feature.
• Other target such as fuchsia or BSDs will also break if system-llvm-libunwind feature is enabled.

My suggestion:

• limit the llvm-libunwind=system option to linux only, as all other system only have one working unwind implementation. ( some changes to build.rs )
• musl target should follow the llvm-libunwind feature and system-llvm-libunwind feature. ( some changes to lib.rs )
• check whether 8d2f80b is unnecessary now
• fix Building rustc in Clang 9.0 error: invalid argument '-std=c++11' not allowed with 'C' #69222

[petrochenkov]

• in-tree will compile the intree copy of llvm-libunwind, and link it into libunwind.rlib

If this is implemented, then I suggest following the approach from #72274 ("Distribute libc.a as a separate library instead of bundling it into liblibc.rlib on musl and wasi") for the in-tree case.

[mati865]

limit the llvm-libunwind=system option to linux only, as all other system only have one working unwind implementation. ( some changes to build.rs )

There is no such target for Rust yet but on Windows with mingw-w64 there are toolchains allowing switching between libgcc and libunwind, also there are even toolchains using libunwind exclusively.

[12101111]

There is no such target for Rust yet but on Windows with mingw-w64 there are toolchains allowing switching between libgcc and libunwind, also there are even toolchains using libunwind exclusively.

Currently libgcc_s on windows_gnu is pulled in

rust/compiler/rustc_target/src/spec/windows_gnu_base.rs

Lines 42 to 60 in 6f9df55

	let dynamic_unwind_libs = vec![
	// If any of our crates are dynamically linked then we need to use
	// the shared libgcc_s-dw2-1.dll. This is required to support
	// unwinding across DLL boundaries.
	"-lgcc_s".to_string(),
	];
	late_link_args_dynamic.insert(LinkerFlavor::Gcc, dynamic_unwind_libs.clone());
	late_link_args_dynamic.insert(LinkerFlavor::Lld(LldFlavor::Ld), dynamic_unwind_libs);
	let static_unwind_libs = vec![
	// If all of our crates are statically linked then we can get away
	// with statically linking the libgcc unwinding code. This allows
	// binaries to be redistributed without the libgcc_s-dw2-1.dll
	// dependency, but unfortunately break unwinding across DLL
	// boundaries when unwinding across FFI boundaries.
	"-lgcc_eh".to_string(),
	"-l:libpthread.a".to_string(),
	];
	late_link_args_static.insert(LinkerFlavor::Gcc, static_unwind_libs.clone());
	late_link_args_static.insert(LinkerFlavor::Lld(LldFlavor::Ld), static_unwind_libs);

It's possible to migrate the logic to libunwind

rust/library/unwind/build.rs

Lines 40 to 43 in 6f9df55

	} else if target.contains("pc-windows-gnu") {
	// This is handled in the target spec with late_link_args_[static|dynamic]
	} else if target.contains("uwp-windows-gnu") {
	println!("cargo:rustc-link-lib=unwind");

[mati865]

Yeah, it was outlined in #72241 (comment) but I haven't got time to investigate it further.

[petrochenkov]

Yeah, it was outlined in #72241 (comment) but I haven't got time to investigate it further.

This needs compiler support (evaluation of cfg predicates in #[link] attributes at link time instead of expansion time) which is in my work queue, but I never got to it either.