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 compile
could be similarly affected - @alexcrichton, any opinion?
alexcrichton commented on issue #1940:
The format of the ELF with
wasmtime compile
isn'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)) )
wasm2obj
seems 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_0
Instead of
_wasm_function_0
, I was expectinghelloFunc
.This behavior is still the same with the following
hello.wat
declaring the export a different way:(module (func (result i32) (i32.const 42)) (export "helloFunc" (func 0)) )
I've tested this on Wasmtime
master
as of this writing, which is commit c91a9313b. As shown above, I observed this behavior on both Linux and macOS.
Last updated: Nov 22 2024 at 17:03 UTC