Exporting _Unwind_* symbols from libstd

[petrhosek]

We use the llvm-unwind feature which means that we build LLVM's libunwind and statically link it into Rust's libunwind. This is critical for our use cases because there's no system unwinder (e.g. libunwind or libgcc) available on systems we target (both Linux and Fuchsia).

dbebcee changed the Rust backend behavior where it no longer exports C symbols from rlibs and dylibs. This means that libstd no longer exports _Unwind_* symbols (that came from LLVM's libunwind which was built as part unwind rlib) and since no other library provides these symbols in our Rust toolchain, any crate that uses unwinding fails to link, most notably rustc itself:

  = note: ld.lld: error: build/x86_64-unknown-linux-gnu/stage1-rustc/x86_64-unknown-linux-gnu/release/deps/librustc_driver-3561bb4b801d0722.so: undefined reference to _Unwind_Resume
          ld.lld: error: build/x86_64-unknown-linux-gnu/stage1-rustc/x86_64-unknown-linux-gnu/release/deps/librustc-fef1aa24ee35e8f2.so: undefined reference to _Unwind_FindEnclosingFunction
          ld.lld: error: build/x86_64-unknown-linux-gnu/stage1-rustc/x86_64-unknown-linux-gnu/release/deps/librustc-fef1aa24ee35e8f2.so: undefined reference to _Unwind_GetIP
          ld.lld: error: build/x86_64-unknown-linux-gnu/stage1-rustc/x86_64-unknown-linux-gnu/release/deps/librustc-fef1aa24ee35e8f2.so: undefined reference to _Unwind_Backtrace

While I think that dbebcee behavior is desirable in general, it's undesirable in this specific case and I'd like to somehow mark _Unwind_* symbols to be exported if llvm-unwind feature is enabled, but I haven't found a way to do so.

cc @alexcrichton @Zoxc @cramertj @tmandry

[Zoxc]

It probably make sense to still export C symbols which are exported from Rust crates.

A workaround might be to export a dummy generic function in libunwind which calls the C functions.

[petrhosek]

I tried the suggested workaround but it doesn't seem to be working.

[Zoxc]

I see we only export C symbols if #[link(name = "unwind", kind = "static")] is on the extern blocks, which libunwind.rs lacks. That's probably the solution here.

[alexcrichton]

FWIW I think that the original change here only affects rust dylibs, when using rlibs we already limited symbols pretty aggressively and AFAIK it's only dylibs which were tweaked. Additionally basically the only project in the world using Rust dylibs is rustc, so the breakage here at least makes sense in that regard and I don't think is cause for alarm yet in terms of maybe there's more breakage lurking.

That being said we should still fix this particular use case! I think @Zoxc is right in that if rustc determines that a C symbol is both statically linked into a Rust dylib (which it deduces via a #[link] annotation) and the C symbol is publicly visible in Rust (aka foreign crates could then access it) then it should make the symbol visible. I'm not sure what the exact incantation is but there should be a way to define a name in Rust with #[link] and then it's hooked up to something explicitly printed by the build script which is actually where the static linkage happens.

@petrhosek if that's too vague though I can try to dig in more to actually remember the incantation here.