bytecodealliance
libunwind warning when compiling a wasmtime project against musl
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...
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...
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
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.
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.
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.
You can use weak symbols from inline asm, right? Would require a separate implementation for each architecture though.
Oh? I had no idea! If that works that might be a reasonable way to go here
We are encountering this in Spin with Wasmtime v25.0.0: https://github.com/fermyon/spin/issues/2889
