Deduplication of functions containing inline assembly contradicts Reference's documentation about code-patching.

[zachs18]

(I'm not sure if this should be considered a codegen bug (i.e. the Reference is correct) or a documentation bug (i.e. the codegen is correct). This issue assumes it is a codegen bug. If this is determined to be a documentation bug, then I can instead report this on the rust-lang/reference repo).

I tried this code:

#![no_std]
use core::arch::asm;
pub fn foo() {
    unsafe { asm!("nop"); }
}
pub fn bar() {
    unsafe { asm!("nop"); }
}

View the resulting assembly using either godbolt.org or cargo-show-asm.

I expected to see this happen: foo and bar are not deduplicated, due to the Rust Reference's documentation that

The compiler cannot assume that the instructions in the asm are the ones that will actually end up executed.
This effectively means that the compiler must treat the asm! as a black box and only take the interface specification into account, not the instructions themselves.
Runtime code patching is allowed, via target-specific mechanisms.

# expected output for --target x86_64-unknown-linux-gnu
example::foo:
  push rax
  
  nop
  
  pop rax
  ret

example::bar:
  push rax
  
  nop
  
  pop rax
  ret

Instead, this happened: When compiled with optimizations (-Copt-level=2 or above), foo and bar are deduplicated (godbolt link)

# actual output for --target x86_64-unknown-linux-gnu
example::bar:
  push rax
  
  nop
  
  pop rax
  ret

Notes:

• This only happens when the asm invocations are exactly the same, thus a workaround is to add spaces to the asm template string to make them different.
• Different extern "ABI" and #[no_mangle] do not inherently prevent deduplication.
• Different #[link_section = "..."]s work to prevent deduplication (if the functions are given the same #[link_section = "..."] then they are still deduplicated).

Meta

Happens on nightly (2023-10-16), stable (1.73.0), and 1.59.0 (when inline asm was stabilized) (and probably all versions between).

rustc --version --verbose:

rustc 1.75.0-nightly (49691b1f7 2023-10-16)
binary: rustc
commit-hash: 49691b1f70d71dd7b8349c332b7f277ee527bf08
commit-date: 2023-10-16
host: x86_64-unknown-linux-gnu
release: 1.75.0-nightly
LLVM version: 17.0.2

rustc 1.73.0 (cc66ad468 2023-10-03)
binary: rustc
commit-hash: cc66ad468955717ab92600c770da8c1601a4ff33
commit-date: 2023-10-03
host: x86_64-unknown-linux-gnu
release: 1.73.0
LLVM version: 17.0.2

(no backtrace)

@rustbot label +A-inline-assembly

[workingjubilee]

@zachs18 can you test specifically with -Zmerge-functions?

[the8472]

The compiler cannot assume that the instructions in the asm are the ones that will actually end up executed.
This effectively means that the compiler must treat the asm! as a black box and only take the interface specification into account, not the instructions themselves.
Runtime code patching is allowed, via target-specific mechanisms.

This language could be interpreted as the compiler cannot make assumptions about the assembly because they might get patched, without actually promising that all assembly blocks can be patched in useful ways.

It might some annotation to opt out of unnamed_addr in the IR.

[zachs18]

@workingjubilee Yes, -Zmerge-functions=disabled does make the functions not be merged (godbolt link).

[workingjubilee]

This language could be interpreted as the compiler cannot make assumptions about the assembly because they might get patched, without actually promising that all assembly blocks can be patched in useful ways.

That's certainly already what happens in some cases?
Given

#![no_std]
use core::arch::asm;
pub fn foo<A>() {
    unsafe { asm!("nop"); }
}

fn main() {
    let _ = foo::<u16>();
    let _ = foo::<i32>();
    let _ = foo::<f64>();
}

The compiler does not promise there will be exactly three nops in the program.

[asquared31415]

I'm not sure there's a way to locate instructions in a non-naked function in ways that are guaranteed to work by Rust. There can be arbitrary code around the asm, so an exported fn symbol doesn't suffice. You can't export a symbol from the asm! because it's not guaranteed that it's only emitted once, so there would be conflicting symbols. The best thing I can think of is inserting a well known constant pattern and searching for that, but I'm not sure if it's permitted to read the bytes of a function (maybe only via assembly and that's arch specific?)

However this bug also occurs with #[naked] functions where it would be possible to modify the asm using the exported function symbol, so there's at least a bug there, even if the compiler would be permitted to merge non-naked functions.

[asquared31415]

@rustbot label -needs-triage +T-compiler +A-codegen

[workingjubilee]

I'm not sure there's a way to locate instructions in a non-naked function in ways that are guaranteed to work by Rust. There can be arbitrary code around the asm, so an exported fn symbol doesn't suffice. You can't export a symbol from the asm! because it's not guaranteed that it's only emitted once, so there would be conflicting symbols. The best thing I can think of is inserting a well known constant pattern and searching for that, but I'm not sure if it's permitted to read the bytes of a function (maybe only via assembly and that's arch specific?)

...Technically, a SIGILL is always guaranteed to find the instructions, no?

[saethlin]

cc @rust-lang/opsem is this a soundness hole?