Semantics of function pointers with equal addresses?

[theemathas]

Consider the following code:

#[unsafe(no_mangle)]
fn foo(x: *mut i32, y: *mut i32) {
    unsafe {
        let a = &mut *x;
        let b = &mut *y;
        *a = *b;
    }
}

#[unsafe(no_mangle)]
fn bar(x: *mut i32, y: *mut i32) {
    unsafe {
        x.write(y.read());
    }
}

On rust version 1.91.0, the above code compiles to this assembly (Godbolt link):

bar:
        mov     eax, dword ptr [rsi]
        mov     dword ptr [rdi], eax
        ret

foo = bar

That is, the two functions are deduplicated, and therefore have the same address. This happened even though these two functions have different behavior in the abstract machine: the foo function has UB if x and y alias, while the bar function doesn't.

Suppose that some code casts these two functions into usize addresses (which are equal to each other), does some operation with those two usizes, and then transmutes an equal usize back into a function pointer. When calling that created function pointer, what is the behavior of that call? Does the call behave like calling foo or calling bar?

In theory, we probably also want (in the future) to potentially allow LLVM to deduplicate functions with incompatible ABIs, as long as their generated assembly are identical. This complicates the above question even further.

A similar question applies to deduplicated vtables.

[purplesyringa]

An example unrelated to SB would be:

fn f() { core::intrinsics::abort() }
unsafe fn g() { unsafe { core::hint::unreachable_unchecked() } }

In practice, LLVM often lowers unreachable_unchecked to ud2 on x86, so these functions are likely to have identical code and thus be subject to merging. So, if it so happens that f as usize == g as usize, what should the AM behavior look like to ensure (g as usize as fn())() doesn't trigger UB? I'd say it should be angelic nondet, just like for exposed provenance in data pointers.

(A funny variation:)

unsafe fn f(b: bool) { unsafe { core::hint::assert_unchecked(b); } }
unsafe fn g(b: bool) { unsafe { core::hint::assert_unchecked(!b); } }
fn test(b: bool) { // should be sound; fight me
    if f as usize == g as usize {
        let fg = unsafe { core::mem::transmute::<usize, fn(bool)>(f as usize) };
        fg(b);
    }
}

[theemathas]

I would argue that even this ought to be sound:

unsafe fn f(b: bool) { unsafe { core::hint::assert_unchecked(b); } }
unsafe fn g(b: bool) { unsafe { core::hint::assert_unchecked(!b); } }
fn test(b: bool) {
    if f as usize == g as usize {
        unsafe { (f as unsafe fn(bool))(b); }
    }
}

[theemathas]

Apparently, in C++, different functions must always have different addresses (subject to as-if rule). https://stackoverflow.com/questions/26533740/do-distinct-functions-have-distinct-addresses

[RalfJung]

That is, the two functions are deduplicated, and therefore have the same address. This happened even though these two functions have different behavior in the abstract machine: the foo function has UB if x and y alias, while the bar function doesn't.

This is not, in fact, decided -- Tree Borrows allows aliasing x and y.
That said, it is definitely possible to construct Rust functions that are different in the AM, but that compile to the same assembly.

---

This is related to #340.

In the model as currently implemented by Miri, function pointers have provenance, and the provenance determines the actual function being called. That makes the "(A funny variation:)" UB since the pointer you are calling has no provenance, and it makes this unambiguously call f. For the original question, it would help to make this a full self-contained example by actually writing out the Rust code that calls it (the devil is in the details), but presuming proper use of with_exposed_provenance, this becomes part of the general question of which provenance that operation picks up. Under the angelic model, it would "do the right thing". The angelic model is however not suited to analyze which optimizations are correct, so this is still potentially problematic.

If function pointers do not have provenance then it seems like we have to say something like, it angelically picks some function with that address. That has the same issues wrt angelic choice, of course.

[gereeter]

This is also related to #206 and #328 (to bring up my apparently favorite issue again); we still haven't ruled out data pointers with equal addresses pointing to different things.