bytecodealliance / wasmtime

A fast and secure runtime for WebAssembly
https://wasmtime.dev/
Apache License 2.0
14.82k stars 1.24k forks source link

libunwind warning when compiling a wasmtime project against musl #8897

Open pimeys opened 5 days ago

pimeys commented 5 days ago

Test Case

Load any wasm component (wasip2) with wasmtime 21.0.1, if you compile the rust host against musl, a warning is printed to the terminal:

libunwind: __unw_add_dynamic_fde: bad fde: FDE is really a CIE

The component and the whole system works correctly, but the log is confusing and there's no way to tell if something is actually broken.

Expected Results

It should work as with builds against glibc, or builds on macos with no libunwind warning printed to the terminal.

Actual Results

I can't seem to find anything being broken really...

Versions and Environment

Wasmtime version or commit: 21.0.1

Operating system: nixos linux unstable

Architecture: x86_64-unknown-linux-musl for the host and wasm32-wasip1 for the guest.

Extra Info

I found issues from the past, such as

https://github.com/wasmerio/wasmer/issues/2150 https://github.com/bytecodealliance/wasmtime/issues/1904

But nothing more recent...

fitzgen commented 5 days ago

Seems like a regression of #1904 and #1914.

FWIW, we do not rely on the system's libunwind for correctness, we only emit .eh_frame and call __register_frame for the benefit of tools like profilers. You can also turn this off via https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.native_unwind_info

IIRC, different libc implementations have different signatures for __register_frame, and this might be what we are running into here. If so, that isn't really something we can fix...

fitzgen commented 5 days ago

IIRC, different libc implementations have different signatures for __register_frame, and this might be what we are running into here. If so, that isn't really something we can fix...

Context:

https://github.com/bytecodealliance/wasmtime/blob/58b4d093fa03e112533fd3dd96bd68792f9e13a4/crates/wasmtime/src/runtime/vm/sys/unix/unwind.rs#L19-L34

pimeys commented 5 days ago

Is there any way to hide this message or will it break any functionality?

fitzgen commented 5 days ago

I believe it is the libunwind implementation printing the message, not Wasmtime.

You can turn off Wasmtime's generation of unwind info via https://docs.rs/wasmtime/latest/wasmtime/struct.Config.html#method.native_unwind_info which should make it so that the message stops printing.

pimeys commented 4 days ago

Yeah, this solved it for us. I don't really know should I close this issue or not. It's kind of still an issue if wanting to use the native unwind info, but also wanting to target musl.

alexcrichton commented 6 hours ago

This cropping up again is a consequence of https://github.com/bytecodealliance/wasmtime/pull/8028 and how dlsym looks like it always returns NULL in a static build. This means that if you build a static binary, which I believe you're doing here, then it'll always think it's using libgcc which is incorrect.

So effectively this boils down to the mechanism used to detect libgcc-vs-libunwind. Another possible option is to use weak symbols but that's not possible in stable Rust so would require some C trickery to do that. I don't know of other options myself.

bjorn3 commented 6 hours ago

You can use weak symbols from inline asm, right? Would require a separate implementation for each architecture though.

alexcrichton commented 6 hours ago

Oh? I had no idea! If that works that might be a reasonable way to go here