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

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.

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

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.

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.

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

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?

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

I just came across a very similar issue here.

However, while it could be argued that two actually identical functions like in the original example might get deduplicated, my issue here is that apparently code is getting deduplicated just based on the text-contents of the asm block, even though repeating the block in two different functions has different meaning.
This basically defines a static variable in assembler and returns a pointer to it, so any repetition of the exact same inline-assembler code is semantically different.

use std::arch::asm;
use std::hint::black_box;

fn foo_() -> *mut u64 {
    let p: *mut u64;
    unsafe {
        asm! {
            "lea {p},[rip + 1f]",
            ".pushsection .bss",
            ".align 8",
            "1:",
            ".quad 0",
            ".popsection",
            p = out(reg) p,
        }
    };
    p
}

fn foo() -> *mut u64 {
    let f: fn() -> _ = black_box(foo_); // prevent inlining
    f()
}

fn bar_() -> *mut u64 {
    let p: *mut u64;
    unsafe {
        asm! {
            "lea {p},[rip + 1f]",
            ".pushsection .bss",
            ".align 8",
            "1:",
            ".quad 0",
            ".popsection",
            p = out(reg) p,
        }
    };
    p
}

fn bar() -> *mut u64 {
    let f: fn() -> _ = black_box(bar_); // prevent inlining
    f()
}

fn main() {
    println!("{:x?} {:x?}", foo(), bar());
}

The two addresses printed should be different, but they are identical due to the incorrect code-deduplication.

I'm not enitirely sure if this should be considered a separate issue instead, since the case for this being incorrect is a lot stronger than the original issue.

Furthermore, I would also expect any inlining of one of the functions to return the same address, which it currently doesn't, likely for the same reason. The only way the asm instructions should currently be allowed to be repeated verbatim and thus generate a different static variable for the same function call is if it is used inside generic code which is monomorphisized in different code-generation units (The reason for that is the the same reason we currently can't have any generic static variables, which is annoying, but a different issue).

@Amanieu what is the expected behavior here?

The current behavior is correct: the compiler is allowed to deduplicate identical inline assembly. Perhaps this could be clarified in the documentation.

Essentially, if you intend to do any kind of hot patching then you need some way to uniquely identify the assembly that you intend to patch. This is usually done by recording the address of the assembly code in a separate section like this:

0:
    my_patchable_instruction

.section patch_list, "a"
.balign 8
.quad 0b
.previous

This will work correctly no matter how many times the asm is duplicated or deduplicated since you'll just end up with more or fewer entries in the patch_list section. If you need different behavior for different blocks then you should use different section names, which will inhibit deduplication.

Should this be mentioned or at least hinted at in the documentation? I can see how the current docs (quoted in the OP) could lead to misunderstandings here.

rust-lang/reference#1441