bjorn3 commented on issue #1940:
Wasm2obj has been deleted in favor of
wasmtime compile, so this can be closed I think.
akirilov-arm commented on issue #1940:
Yes, but
wasmtime compilecould be similarly affected - @alexcrichton, any opinion?
alexcrichton commented on issue #1940:
The format of the ELF with
wasmtime compileisn't a public implementation detail so it's not intended to be consumed elsewhere, so because it's purely an implementation detail I'm gonna close this. Eventually we'll want a public-facing object-file format, but this will almost surely be addressed in such an implementation.
alexcrichton closed issue #1940:
Not sure if this is a bug, my own user error, or just a not-implemented-yet.
I have the following minimal Wasm example (hello.wat):
(module (func (export "helloFunc") (result i32) (i32.const 42)) )
wasm2objseems to not respect the declared export function name:(Linux) > wasmtime wasm2obj hello.wat hello.o > nm hello.o 0000000000000000 D _vmcontext_init 0000000000000000 T _wasm_function_0(macOS) > wasmtime wasm2obj hello.wat hello.o > nm hello.o 000000000000000e D __vmcontext_init 0000000000000000 T __wasm_function_0Instead of
_wasm_function_0, I was expectinghelloFunc.This behavior is still the same with the following
hello.watdeclaring the export a different way:(module (func (result i32) (i32.const 42)) (export "helloFunc" (func 0)) )I've tested this on Wasmtime
masteras of this writing, which is commit c91a9313b. As shown above, I observed this behavior on both Linux and macOS.
Last updated: Dec 06 2025 at 06:05 UTC