Description
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.
Activity
Zoxc commentedon Jun 24, 2019
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 commentedon Jun 25, 2019
I tried the suggested workaround but it doesn't seem to be working.
Zoxc commentedon Jun 26, 2019
I see we only export C symbols if
#[link(name = "unwind", kind = "static")]
is on the extern blocks, whichlibunwind.rs
lacks. That's probably the solution here.alexcrichton commentedon Jun 26, 2019
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.
await!(future)
macro #62293Rollup merge of rust-lang#62287 - petrhosek:libunwind-link-attribute,…
Rollup merge of rust-lang#62287 - petrhosek:libunwind-link-attribute,…
Rollup merge of rust-lang#62287 - petrhosek:libunwind-link-attribute,…
Rollup merge of rust-lang#62287 - petrhosek:libunwind-link-attribute,…
10 remaining items