Replies: 1 comment
-
Hello, I believe it can be much “simpler” and more versatile to trace the VM execution rather than instrumenting the Wasm module (see #2152). Otherwise, I don't believe it's a good idea to instrument the Wasm module at runtime, it should be done as part of a pre-processor (see #1210) maybe. Since we can also compile Wasm modules to native objects, we can probably use I think we should come with a solution to cover most usecases. cc @wchaudry |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Summary
I'm trying to write a piece of middleware for profiling Wasm code blocks. For this, I'm trying to inject a couple function imports and a little Wasm code that would call the imported functions before a block and after it.
What would be a good way to inject those imports? So far I haven't been able to make it happen.
Additional details
I've been trying to mutate
ModuleInfo
to include the new imports, but that seems to confuse existing local functions in the module. I didn't dig too deep, but I'm guessing things get tricky because normally imported functions would be indexed first, and local ones later?Here's some code I stripped down to a sort-of MWE:
https://gist.github.com/uint/be1d83734a76d8cb79cc09c2b0b2a753
Here's the output:
Note the
start measuring
print. This means that instead of the expected local function being called my import got confused here and is being called.Edit: Also note that if you comment out the middleware code, the test passes.
Beta Was this translation helpful? Give feedback.
All reactions