Why is "cargo clean" required to get my inline asm to work?

ZiCog · April 7, 2025, 12:32pm

Wow, seems like I stumbled on a high priority soundness bug in the compiler that is not actually anything to do with any asm. Nice I could contribute a little something to the Rust project.

ZiCog · April 12, 2025, 7:48am

Yay, this problem is now fixed in the latest nightly.

cargo --version --verbose
cargo 1.88.0-nightly (0e93c5bf6 2025-04-05)
release: 1.88.0-nightly
commit-hash: 0e93c5bf6a1d5ee7bc2af63d1afb16cd28793601
commit-date: 2025-04-05
host: aarch64-apple-darwin
libgit2: 1.9.0 (sys:0.20.0 vendored)
libcurl: 8.7.1 (sys:0.4.80+curl-8.12.1 system ssl:(SecureTransport) LibreSSL/3.3.6)
ssl: OpenSSL 3.4.1 11 Feb 2025
os: Mac OS 15.4.0 [64-bit]

github.com/rust-lang/rust

Instructions missing from naked_asm blocks.

opened 11:09AM - 05 Apr 25 UTC

closed 04:59PM - 11 Apr 25 UTC

ZiCog

regression-from-stable-to-nightly P-high T-compiler I-unsound A-incr-comp C-bug

Instructions are getting omitted from naked_asm blocks after fixing a compilatio…n error and then rebuilding with `cargo run`. A `cargo clean` and `cargo run` is then required to get a correct executable. As a minimal demonstration of this problem this code contains a deliberate error and fails to build: ``` #![feature(naked_functions)] #![no_main] use core::arch::naked_asm; #[unsafe(no_mangle)] #[naked] extern "C" fn add_u64(x: u64, y: u64) -> u64 { unsafe { naked_asm!("add x0, x0, w1", "ret") } } #[unsafe(no_mangle)] pub extern "C" fn main(_argc: isize, _argv: *const *const u8) -> isize { println!("{}", add_u64(3u64, 7u64)); 0 } ``` ``` cargo run Compiling rust_asm v0.1.0 (/Users/me/rust_asm) error: too few operands for instruction | note: instantiated into assembly here --> <inline asm>:5:1 | 5 | add x0, x0, w1 | ^^^^^^^^^^^^^^ ``` We fix the source by changing `w1` into `x1`. Which now builds without error but produces the wrong result: ``` #![feature(naked_functions)] #![no_main] use core::arch::naked_asm; #[unsafe(no_mangle)] #[naked] extern "C" fn add_u64(x: u64, y: u64) -> u64 { unsafe { naked_asm!("add x0, x0, x1", "ret") } } #[unsafe(no_mangle)] pub extern "C" fn main(_argc: isize, _argv: *const *const u8) -> isize { println!("{}", add_u64(3u64, 7u64)); 0 } ``` ``` cargo run Compiling rust_asm v0.1.0 (/Users/me/rust_asm) Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.14s Running `target/debug/rust_asm` 3 ``` Looking at the disassembled executable with `objdump -d target/debug/rust_asm | less` we find the `add` instruction is missing from the `add_u64()` function: ``` 00000001000018d0 <_add_u64>: 1000018d0: d65f03c0 ret ``` Rebuilding with `cargo clean` and `cargo run` then produces the correct result: ``` cargo clean Removed 41 files, 1.0MiB total cargo run Compiling rust_asm v0.1.0 (/Users/me/rust_asm) Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.36s Running `target/debug/rust_asm` 10 ``` And of course the `add` instruction is now in the executable where we expect it to be: ``` 00000001000018cc <_add_u64>: 1000018cc: 8b010000 add x0, x0, x1 1000018d0: d65f03c0 ret ``` ### Meta ``` rustc --version --verbose rustc 1.87.0-nightly (249cb8431 2025-03-12) binary: rustc commit-hash: 249cb84316401daf040832cdbb8a45e0f5ab6af8 commit-date: 2025-03-12 host: aarch64-apple-darwin release: 1.87.0-nightly LLVM version: 20.1.0 ```

khimru · April 12, 2025, 10:26am

That's actually big difference between C culture and Rust culture.

In a C world (especially in embedded) I saw some really horrible hacks designed to work around some exotic bugs in a compiler – yet people rarely report them.

Because there are no point in doing that: vendors give you some compiler based on decade old GCC (today they have switched to five years old clang… big progress!) and even if you report a bug… it may take 10 or 20 years before you may remove your kludge.

With Rust's “living at the ToT” way of doing things “reporting and fixing bug” activity is actually useful for the reporter.

P.S. This being said, you still have to keep in mind that for 100 times when you think… “no, that's not possible, there are something wrong with the compiler…” 99 times it's your fault, 1 time it's the compiler bug. Verify your “compiler bugs” carefully before reporting them, there are no need to clog the bug-reporting pipes with bugs that are not bugs.

ZiCog · April 12, 2025, 12:57pm

Oh my God, so true. Back in the day it was mandated that our project will use WindRiver's VxWorks operating system. Because, you know, "safety critical", certifications, standards, "they use it on Mars" and all that. Well the GCC shipped with VxWorks crashed while compiling my code, which gave me little confidence in what it might generate. After suffering that and numerous other problems I managed to get permission to switch to Linux. Life was good and that system is still running all over Scandinavia fifteen years later.

Indeed, finding a compiler bug is amazingly rare. It's almost always my fault. So it was very helpful to have the discussion about it here first.

Topic		Replies	Views
Problem using inline assembly help	7	2147	January 12, 2023
[SOLVED] Linking asm into crate help	3	2980	January 12, 2023
Inline assembly: extra `push rax`, `pop rcx` added to function help	3	1700	December 24, 2020
Is unchecked assembly possible?	11	287	April 11, 2025
--emit=asm changes the produced machine code help	4	2877	January 12, 2023

Why is "cargo clean" required to get my inline asm to work?

Related topics