Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Panic in LLVM when using #[linkage] even with supported targets #33992

Closed
mattico opened this issue May 31, 2016 · 5 comments
Closed

Panic in LLVM when using #[linkage] even with supported targets #33992

mattico opened this issue May 31, 2016 · 5 comments

Comments

@mattico
Copy link
Contributor

mattico commented May 31, 2016

λ cargo new test-linkage
λ cd test-linkage
λ cat src/lib.rs
#![feature(linkage)]

#[linkage = "extern_weak"]
pub static TEST: bool = false;

λ env RUST_BACKTRACE=1 cargo build --verbose # OR
λ env RUST_BACKTRACE=1 cargo build --verbose --target x86_64-unknown-linux-gnu
   Compiling test-linkage v0.1.0 (file:///C:/Users/Matt%20Ickstadt/Code/Rust/test-linkage)
     Running `rustc src\lib.rs --crate-name test_linkage --crate-type lib -g --out-dir "C:\Users\Matt Ickstadt\Code\Rust\test-linkage\target\x86_64-unknown-linux-gnu\debug" --emit=dep-info,link --target x86_64-unknown-linux-gnu -L "dependency=C:\Users\Matt Ickstadt\Code\Rust\test-linkage\target\x86_64-unknown-linux-gnu\debug" -L "dependency=C:\Users\Matt Ickstadt\Code\Rust\test-linkage\target\x86_64-unknown-linux-gnu\debug\deps"`
Don't know how to emit these
UNREACHABLE executed at C:/bot/slave/nightly-dist-rustc-win-gnu-32/build/src/llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp:336!

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
error: Could not compile `test-linkage`.

Caused by:
  Process didn't exit successfully: `rustc src\lib.rs --crate-name test_linkage --crate-type lib -g --out-dir C:\Users\Matt Ickstadt\Code\Rust\test-linkage\target\x86_64-unknown-linux-gnu\debug --emit=dep-info,link --target x86_64-unknown-linux-gnu -L dependency=C:\Users\Matt Ickstadt\Code\Rust\test-linkage\target\x86_64-unknown-linux-gnu\debug -L dependency=C:\Users\Matt Ickstadt\Code\Rust\test-linkage\target\x86_64-unknown-linux-gnu\debug\deps` (exit code: 3)

Nothing too unexpected, since most targets don't support weak linkage. The error message could be a bit better though, rather than panicing in LLVM.

I was a bit surprised that this problem persists when cross compiling to supported targets, but I suppose that its an LLVM limitation, and a very niche one at that.

cc #29603

@mattico
Copy link
Contributor Author

mattico commented May 31, 2016

Just ran this on Ubuntu, expecting it to work, and it didn't. I guess this isn't Windows issue after all.

Am I using this attribute incorrectly? Does it work?

@mattico mattico changed the title Panic in LLVM when using #[linkage] on Windows, even with supported targets Panic in LLVM when using #[linkage] even with supported targets May 31, 2016
@mattico
Copy link
Contributor Author

mattico commented May 31, 2016

Well it works with #[linkage = "weak"] so I'm starting to think that LLVM changed/removed "extern_weak".

@mattico
Copy link
Contributor Author

mattico commented May 31, 2016

@mattico
Copy link
Contributor Author

mattico commented May 31, 2016

I'm putting together a PR with the fix and some compile-pass tests. Might take a few hours to compile, though 😢

mattico added a commit to mattico/rust that referenced this issue Jun 1, 2016
The `Linkage` enum in librustc_llvm got out of sync with the version in LLVM and it caused two variants of the #[linkage=""] attribute to break.

Fixes rust-lang#33992
mattico added a commit to mattico/rust that referenced this issue Sep 2, 2016
The `Linkage` enum in librustc_llvm got out of sync with the version in LLVM and it caused two variants of the #[linkage=""] attribute to break.

This adds the functions `LLVMRustGetLinkage` and `LLVMRustSetLinkage` which convert between the Rust Linkage enum and the LLVM one, which should stop this from breaking every time LLVM changes it.

Fixes rust-lang#33992
Manishearth added a commit to Manishearth/rust that referenced this issue Sep 4, 2016
…chton

Fix incorrect LLVM Linkage enum

Followup of rust-lang#33994 to actually work.

The `Linkage` enum in librustc_llvm got out of sync with the version in LLVM and it caused two variants of the `#[linkage=""]` attribute to break.

This adds the functions `LLVMRustGetLinkage` and `LLVMRustSetLinkage` which convert between the Rust Linkage enum and the LLVM one, which should stop this from breaking every time LLVM changes it.

Possible remaining concerns:

1. There could be a codegen test to make sure that the attributes are applied correctly (I don't know how to do this).
2. The test does not exercise the `appending` linkage. I can't figure out how to make a global static raw pointer to an array. This might not even be possible? If not we should probably remove appending linkage as its unusable in rust.
3. The test only runs on Linux.

Fixes rust-lang#33992

r? @alexcrichton
@TimNN
Copy link
Contributor

TimNN commented Sep 4, 2016

Edit: This was meant to be posted to the corresponding pull request.


---- [run-pass] run-pass/issue-33992.rs stdout ----

error: compilation failed!
status: signal: 6
command: /buildslave/rust-buildbot/slave/auto-linux-64-opt-rustbuild/build/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustc /buildslave/rust-buildbot/slave/auto-linux-64-opt-rustbuild/build/src/test/run-pass/issue-33992.rs -L /buildslave/rust-buildbot/slave/auto-linux-64-opt-rustbuild/build/obj/build/x86_64-unknown-linux-gnu/test/run-pass --target=x86_64-unknown-linux-gnu --error-format json -L /buildslave/rust-buildbot/slave/auto-linux-64-opt-rustbuild/build/obj/build/x86_64-unknown-linux-gnu/test/run-pass/issue-33992.stage2-x86_64-unknown-linux-gnu.run-pass.libaux -C prefer-dynamic -o /buildslave/rust-buildbot/slave/auto-linux-64-opt-rustbuild/build/obj/build/x86_64-unknown-linux-gnu/test/run-pass/issue-33992.stage2-x86_64-unknown-linux-gnu -Crpath -O -Lnative=/buildslave/rust-buildbot/slave/auto-linux-64-opt-rustbuild/build/obj/build/x86_64-unknown-linux-gnu/rust-test-helpers
stdout:
------------------------------------------

------------------------------------------
stderr:
------------------------------------------
Should never emit this
UNREACHABLE executed at /buildslave/rust-buildbot/slave/auto-linux-64-opt-rustbuild/build/src/llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp:336!

------------------------------------------

mattico added a commit to mattico/rust that referenced this issue Sep 4, 2016
The `Linkage` enum in librustc_llvm got out of sync with the version in LLVM and it caused two variants of the #[linkage=""] attribute to break.

This adds the functions `LLVMRustGetLinkage` and `LLVMRustSetLinkage` which convert between the Rust Linkage enum and the LLVM one, which should stop this from breaking every time LLVM changes it.

Fixes rust-lang#33992
bors added a commit that referenced this issue Sep 5, 2016
Fix incorrect LLVM Linkage enum

Followup of #33994 to actually work.

The `Linkage` enum in librustc_llvm got out of sync with the version in LLVM and it caused two variants of the `#[linkage=""]` attribute to break.

This adds the functions `LLVMRustGetLinkage` and `LLVMRustSetLinkage` which convert between the Rust Linkage enum and the LLVM one, which should stop this from breaking every time LLVM changes it.

Possible remaining concerns:

1. There could be a codegen test to make sure that the attributes are applied correctly (I don't know how to do this).
2. ~~The test does not exercise the `appending` linkage. I can't figure out how to make a global static raw pointer to an array. This might not even be possible? If not we should probably remove appending linkage as its unusable in rust.~~ Appending linkage is not 'emittable' anyway.
3. The test only runs on Linux.

Fixes #33992

r? @alexcrichton
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants