Non existing function imported when compiling for wasm

[athei]

Whenever I try to compile some specific code for wasm32-unknown-unknown with enabled overflow-checks and lto the compiler inserts a function import into the resulting wasm module that looks like this:

(import "env" "_ZN4core9panicking5panic17h80a3410ec4f43255E" (func $_ZN4core9panicking5panic17h80a3410ec4f43255E (type 0))

These are the complete contents of the lib.rs:

#![no_std]

#[panic_handler]
fn my_panic(_info: &core::panic::PanicInfo) -> ! {
    loop {}
}

#[no_mangle]
pub fn multer(a: i128, b: i128) -> i128 {
    // trigger usage of the __multi3 compiler intrinsic which seems to be necessary
    // in order to reproduce the bug
    a * b
}

What seems to trigger the bug are the following conditions:

• The --target must be wasm32-unknown-unknown
• overflow-checks = true
• lto = true
• Recompile core libs with cargo xbuild or the std aware cargo
• The call of the panic function originates in some compiler extrinsic

The minimal reproducer repo contains the exact command line that reproduces the bug.

I expected to see this happen:
The resulting wasm module does not import any function from the environment.

Instead, this happened:
The resulting wasm module imports the previously mentioned panic function from the environment.

Meta

rustc +nightly --version --verbose:

rustc 1.49.0-nightly (ffa2e7ae8 2020-10-24)
binary: rustc
commit-hash: ffa2e7ae8fbf9badc035740db949b9dae271c29f
commit-date: 2020-10-24
host: x86_64-apple-darwin
release: 1.49.0-nightly
LLVM version: 11.0

[jyn514]

@athei AFAIK wasm doesn't support unwinding, I think you need panic = abort in Cargo.toml.

[athei]

@athei AFAIK wasm doesn't support unwinding, I think you need panic = abort in Cargo.toml.

I have.
https://github.com/athei/mult-panic/blob/5ff5fd6a929581b11bea21150c28843407d6df6b/Cargo.toml#L15

That said, it appears that it is disabled automatically if the target spec disables unwinding.

[vminkov]

Does anybody have a solution for this?

[cmichi]

@athei I just tried your reproducer from https://github.com/athei/mult-panic with the latest rustc 1.56.0-nightly (2827db2b1 2021-08-01) and there is no more (import "env" …) in the Wasm. Can you confirm that the bug is no longer existent?

[athei]

I can confirm that the reproducer no longer reproduces the bug with the new rust nightly. This does not necessarily mean that the root cause is fixed, though.

[jyn514]

@athei would you be interested in adding a test for this? I doubt we'll be able to track down the exact cause, but preventing it from regressing seems just as good :)

[athei]

Yes. I would be interested. Can you toss me in the general direction where this test would go (as in which test sub directory)?

[jyn514]

@athei it depends what you need to test - it looks like the code here did compile successfully, it just didn't run, so you'd probably need a new run-make test (since there's no way to run wasm natively).

[athei]

Running isn't required I think. It would be OK to compile it and then look at the binaries imports and fail if there is anything.

[athei]

I guess that would still be a run-make test just that I don't run but inspect the binary?

[jyn514]

@athei yes, that's what I was imagining :)

[h4x3rotab]

I can confirm that the reproducer no longer reproduces the bug with the new rust nightly. This does not necessarily mean that the root cause is fixed, though.

Here's another example reproducing the same problem differently:

https://github.com/Phala-Network/phat-stateful-rollup/tree/8ea712721410a1c28fc9b0a680abf41e2124f3de/phat/sample_oracle

With cargo-contract installed, under this flow, run:

cargo contract build

[tolak]

I can confirm that the reproducer no longer reproduces the bug with the new rust nightly. This does not necessarily mean that the root cause is fixed, though.

Here's another example reproducing the same problem differently:

https://github.com/Phala-Network/phat-stateful-rollup/tree/8ea712721410a1c28fc9b0a680abf41e2124f3de/phat/sample_oracle

With cargo-contract installed, under this flow, run:

cargo contract build

I got it too with cargo contract build with rustc 1.65.0-nightly (c2804e6ec 2022-09-07), fix build with adding following options in Cargo.toml

[profile.release]
overflow-checks = false     # Disable integer overflow checks.
lto = false                 # Enable full link-time optimization. 

[jyn514]

Posting on a closed issue is not a good way to get visibility for this problem. I suggest opening a new issue and linking back to this one.