Skip to content

Exporting _Unwind_* symbols from libstd #62088

Closed
@petrhosek

Description

@petrhosek
Contributor

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

Activity

Zoxc

Zoxc commented on Jun 24, 2019

@Zoxc
Contributor

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

petrhosek commented on Jun 25, 2019

@petrhosek
ContributorAuthor

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

Zoxc

Zoxc commented on Jun 26, 2019

@Zoxc
Contributor

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

alexcrichton commented on Jun 26, 2019

@alexcrichton
Member

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.

added a commit that references this issue on Jul 3, 2019

Rollup merge of rust-lang#62287 - petrhosek:libunwind-link-attribute,…

64135ef
added 3 commits that reference this issue on Jul 3, 2019

Rollup merge of rust-lang#62287 - petrhosek:libunwind-link-attribute,…

a4b9225

Rollup merge of rust-lang#62287 - petrhosek:libunwind-link-attribute,…

288ca93

Rollup merge of rust-lang#62287 - petrhosek:libunwind-link-attribute,…

3bd6234

10 remaining items

Loading
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-LLVMArea: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.C-bugCategory: This is a bug.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @Zoxc@alexcrichton@petrhosek@jonas-schievink@Mark-Simulacrum

        Issue actions

          Exporting _Unwind_* symbols from libstd · Issue #62088 · rust-lang/rust