LLVM error with arithemetic on function addresses

[MarkMcCaskey]

Hello! I was doing some experimenting with Wasm callbacks and ran into 2 issues.

The code for the guest is compiled with Rust 1.37.0 on OSX with --target=wasm32-unknown-unknown and --release.

edit: the first issue is no longer relevant; I misunderstood how function pointers were implemented. By using the table to look up these values, I got it working!

The second issue

While investigating this, I also found that the invalid solution of relying on the guest to offset correctly:

fn main() {
    // offset by 3 because we have 3 imports!
    unsafe { call_guest_fn(test_callback as usize as u32 + 3) };
}

causes an LLVM error:

 cargo build --release --target=wasm32-unknown-unknown
   Compiling guest v0.1.0 (/Users/mark/Documents/temp/guest)
LLVM ERROR: Function addresses with offsets not supported
error: Could not compile `guest`.

To learn more, run the command again with --verbose.

Let me know if I can clarify or help out with this!

[jonas-schievink]

@MarkMcCaskey can you provide the full code needed to reproduce the second issue?

[MarkMcCaskey]

@MarkMcCaskey can you provide the full code needed to reproduce the second issue?

main.rs:

extern "C" {
    fn call_guest_fn(f: u32) -> u32;
}

#[no_mangle]
fn test_callback() -> u32 {
    42
}

fn main() {
    unsafe { call_guest_fn(test_callback as usize as u32 + 1) };
}

$ cargo build --target=wasm32-unknown-unknown
   Compiling guest v0.1.0 (/Users/mark/Documents/temp/guest)
LLVM ERROR: Function addresses with offsets not supported
error: Could not compile `guest`.

To learn more, run the command again with --verbose.

This is a more minor issue than the one I thought I initially had. The reason I think it's an error is just that it exposes LLVM errors directly, if that's not an error then this is the correct behavior. To be clear: given how the table works, this Rust code doesn't make much sense and probably shouldn't work. It may not be possible to detect this on the Rust frontend because it's not a type error as far as Rust can tell. And actually from the perspective of the generated Wasm and Rust, it looks like it should be possible because we're just dealing with numbers, but internally in LLVM it's not just a number.