inline-asm immediate constraint with fn argument crashes LLVM #51130
Labels
A-inline-assembly
Area: Inline assembly (`asm!(…)`)
C-bug
Category: This is a bug.
I-crash
Issue: The compiler crashes (SIGSEGV, SIGABRT, etc). Use I-ICE instead when the compiler panics.
requires-nightly
This issue requires a nightly compiler in some way.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Comments
|
This example causes a segfault in rustc. Because this is very easy to reproduce, I think one can omit to post a full dump here, but nevertheless, here's the backtrace. |
|
LLVM assertion failure: Assertion backtrace: |
|
LLVM IR: Causes assertion failure under |
|
I've reported this issue upstream: https://bugs.llvm.org/show_bug.cgi?id=37624 However, there is also a rustc issue here in that it shouldn't be generating an |
XAMPPRocky
added
A-codegen
Rahix
added a commit
to Rahix/atmega32u4-hal
that referenced
this issue
Oct 9, 2018
When trying to build this crate for non-avr architectures, the compiler segfaults due to a bug when lowering inline assembly. Workaround is to throw another error earlier on and disable the avr assembly parts on other archs. Ref rust-lang/rust#51130 Signed-off-by: Rahix <[email protected]>
|
I've looked a bit closer at what is going on here on the Rust side. The issue seems to be that we're directly using an fn item as an inline asm operand (which is treated as a ZST scalar, yielding an undef), where usually such a use should go through a ReifyFnPointer. This is because in https://github.com/rust-lang/rust/blob/master/src/librustc_typeck/check/mod.rs#L3946 we do not impose any type restrictions on inline asm input operands. We should be introducing a ReifyFnPointer adjustment somehow here, though I'm not sure how to actually do it (we don't really have an expected type here). |
|
For variadic (FFI) calls, we error saying you should cast: rust/src/librustc_typeck/check/mod.rs Lines 2915 to 2916 in 3d28ee3 We should maybe do something similar about inline |
|
We should validate lots and lots of things about the values passed to inline asm, and we currently don't do any of them. That's no reason to not fix it, but it will be a drop in the bucket. |
|
Would it be possible to produce such a list and make a tracking issue for it? |
|
This particular issue seems to be somewhat common. #36907 is another instance. |
|
@mark-i-m I’ve been writing such a list (and fixing some of them) for a while now, so I guess I can make a tracking issue sometime soon. That said, we are eventually gonna get rid of the current semantics in favor of something new. There’s already a Pre-RFC on internals, and I’d hope that we could soon write the actual RFC. |
Centril
added
the
requires-nightly
|
Triage: there hasn't really been any direct changes here, but there has been movement towards entirely re-doing inline assembly; with the current implementation moving to |
|
The equivalent version in the new asm syntax (as implemented by #69171) is: #![feature(asm)]
fn main() {
unsafe { asm!("call {}", sym test); }
}
extern fn test() {} |
|
This issue does not apply to the new The legacy |
|
@Amanieu The obvious equivalent in the new asm, #![feature(asm)]
fn main() {
unsafe { asm!("call {}", sym test); }
}
extern fn test() {}Fails with a linking error. See https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=4c66087def8876f1661239ca3b06c976 . Should I open a new issue? |
|
Yes, please open a new issue for this. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
For some reason, this crashes rustc. However, the following test compiles properly in some cases:
But, in a real world project, the exact same code I get errors such as
error: invalid operand for inline asm constraint 'i'or compile-time segfaults.The text was updated successfully, but these errors were encountered: