Repository navigation
Compiler null dereference when there are conflicting asm labels #74262
Description
Code
#![feature(asm)]
#[inline(always)]
fn f() {
unsafe {
asm!("test: nop");
}
}
fn main() {
f();
f();
}Meta
rustc 1.46.0-nightly (346aec9b0 2020-07-11)
binary: rustc
commit-hash: 346aec9b02f3c74f3fce97fd6bda24709d220e49
commit-date: 2020-07-11
host: x86_64-pc-windows-msvc
release: 1.46.0-nightly
LLVM version: 10.0
Error output
error: invalid symbol redefinition
--> .\crash.rs:6:15
|
6 | asm!("test: nop");
| ^
|
note: instantiated into assembly here
--> <inline asm>:2:2
|
2 | test: nop
| ^
[crash due to null dereference]
Details
This bug only happens when compiling for Windows target with debug information. Command to reproduce crash:
rustc crash.rs --target x86_64-pc-windows-msvc -g
It was identified by eddyb that crash happens in LLVM function WinCOFFObjectWriter::assignFileOffsets.
Metadata
Metadata
Assignees
Labels
Area: Inline assembly (`asm!(…)`)Category: This is a bug.`#![feature(asm)]` (not `llvm_asm`)Issue: The compiler crashes (SIGSEGV, SIGABRT, etc). Use I-ICE instead when the compiler panics.Issue: The compiler never terminates, due to infinite loops, deadlock, livelock, etc.Relevant to the compiler team, which will review and decide on the PR/issue.
Activity
jonas-schievink commentedon Jul 12, 2020
On the playground this seems to hang instead
Amanieu commentedon Jul 15, 2020
The
asm!RFC and documentation specifically say that you should not define labels in inline assembly and instead only use local labels (0:,1:, etc).So your code is invalid, but having the compiler crash on invalid code is still a bug.
asquared31415 commentedon Jan 28, 2021
@rustbot claim
Amanieu commentedon Apr 7, 2021
This no longer seems to crash. Probably fixed by LLVM at some point.
Amanieu commentedon Apr 7, 2021
Actually it seems to still be crashing on
x86_64-pc-windows-gnuandx86_64-pc-windows-msvc.asquared31415 commentedon Oct 21, 2021
#87324 lints against using labels in this way, which is prohibited by the asm RFC and documented. #81088 is the primary issue for an ideal solution that lets this work.
Since this now errors by default, should this be closed?
Amanieu commentedon Oct 21, 2021
Yes, I think we can close this.