-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Inline asm: =m
constraint on uninitialized object variable in impl
block causes the SelectionDAGBuilder to crash rustc with SIGSEGV on Linux and 0xC0000005 on Windows
#71701
Comments
cargo bootimage
attempt when llvm_asm! is being usedcargo bootimage
attempt when large quantities of llvm_asm! is used
cargo bootimage
attempt when large quantities of llvm_asm! is usedcargo bootimage
attempt when large quantities of llvm_asm! is used
cargo bootimage
attempt when large quantities of llvm_asm! is usedcargo bootimage
attempt when large quantities of llvm_asm! is used
cargo bootimage
attempt when large quantities of llvm_asm! is usedcargo bootloader
attempt
Could you post |
And the last nightly to work was one from March ― but that was also from before I wrote the code that triggers the crash. |
Tried switching the argument identifiers around (i.e. |
cargo bootloader
attemptcargo bootimage
attempt
Updated title to fix command-line typo |
Tested on Windows 10 too using VSCode — same problem:
Again: no idea why the LLVM is having trouble building the selection DAG. Only thing I can think of is that perhaps something in the prelude is interfacing with my inline asm in a way that is causing an endless selection DAG building loop that overruns the buffer; trying something else. |
After further testing and further code modification I now know what’s triggering this bug: it’s the That’s still no excuse for the compiler crash though; Rust needs to throw an error instead. |
cargo bootimage
attempt=m
operand causes the SelectionDAGBuilder to crash with SIGSEGV on Linux and 0xC0000005 on Windows
=m
operand causes the SelectionDAGBuilder to crash with SIGSEGV on Linux and 0xC0000005 on Windows=m
operand on uninitialized object variable in “impl” block causes the SelectionDAGBuilder to crash with SIGSEGV on Linux and 0xC0000005 on Windows
=m
operand on uninitialized object variable in “impl” block causes the SelectionDAGBuilder to crash with SIGSEGV on Linux and 0xC0000005 on Windows=m
operand on uninitialized object variable in impl
block causes the SelectionDAGBuilder to crash with SIGSEGV on Linux and 0xC0000005 on Windows
=m
operand on uninitialized object variable in impl
block causes the SelectionDAGBuilder to crash with SIGSEGV on Linux and 0xC0000005 on Windows=m
operand on uninitialized object variable in impl
block causes the SelectionDAGBuilder to crash rusty with SIGSEGV on Linux and 0xC0000005 on Windows
=m
operand on uninitialized object variable in impl
block causes the SelectionDAGBuilder to crash rusty with SIGSEGV on Linux and 0xC0000005 on Windows=m
operand on uninitialized object variable in impl
block causes the SelectionDAGBuilder to crash rustC with SIGSEGV on Linux and 0xC0000005 on Windows
=m
operand on uninitialized object variable in impl
block causes the SelectionDAGBuilder to crash rustC with SIGSEGV on Linux and 0xC0000005 on Windows=m
operand on uninitialized object variable in impl
block causes the SelectionDAGBuilder to crash rustc with SIGSEGV on Linux and 0xC0000005 on Windows
=m
operand on uninitialized object variable in impl
block causes the SelectionDAGBuilder to crash rustc with SIGSEGV on Linux and 0xC0000005 on Windows=m
constraint on uninitialized object variable in impl
block causes the SelectionDAGBuilder to crash rustc with SIGSEGV on Linux and 0xC0000005 on Windows
Updated the title to better reflect the additional information gathered from further testing and further editing. What needs to happen: Rust needs to throw |
I would also like to point out that your code is also broken in multiple ways:
Basically, the whole function should be implemented as a single inline assembly block. |
This issue does not apply to the new The legacy |
I tried this code:
I expected to see this happen:
I get it, that's a lot of inline assembly, but also highly necessary if you're developing an OS ― and backing up registers to initiate a context switch is one of those areas in which developers have no choice but to get down and dirty.
So, using
cargo bootimage
― which definitely worked before I wrote this code ― shouldn't be a problem here, especially given that there are plenty of crates out there that serve, to a degree, as safe abstractions. If the inline assembly has any syntax problems in it (reversed$1
and$0
for example which might be the case here) then the compiler should throw an error, not crash.Instead, this happened:
No compiler errors are output, but the compiler crashes ― with, exactly as the title says, a segmentation fault, using an Arch Linux host.
Here's the GDB output ― and this is using the copied-and-pasted arguments that
cargo bootimage
is passing down torustc
whenever I try to build this project:Note that it's actually
rustc
itself that's segfaulting here ― this here is why I didn't file any bug reports with the cargo-bootimage crate maintainers:cargo bootimage
invokesrustc
to actually do the compiling, using a custom set of parameters that the above gdb output is preserving for posterity.Also, the instruction that rustc is segfaulting in ― again, according to GDB ― is very clearly a line of LLVM inline assembly parsing code:
llvm::SelectionDAGBuilder::visitInlineAsm(llvm::ImmutableCallSite) ()
Since this is really the only part of my project in which I use any inline assembly at all (the
x86_64
crate is of great help elsewhere), I am fairly confident that the problem here is that something in Rust's LLVM implementation just can't handle this much inline assembly at one time. Hopefully there's a way to improve this upstream.The text was updated successfully, but these errors were encountered: