Hi all, where should I be looking at if I want to add embedder-specified hooks to report each wasm function call? The motivation is logging libc allocator calls to detect use-after-free and such
this is not a built-in feature of Wasmtime, but I believe that wasm-opt
allows instrumenting Wasm modules to insert calls to imported tracing functions like this, so you give it a Wasm module and you get out an instrumented Wasm module
we already instrument cranelift IR for fuels right? so i'm just wondering if i can add similar logic but for wasm function calls (and expose that to c api too)
it is certainly technically possible; whether we would want to implement and maintain it feels like something that an RFC would decide
there is also the call_hook
for tracing the transfer of control between the host and wasm, fwiw
i see, thx for answering!
@Cheng Shao a distinction I would make that seems like it could be useful in deciding things like this (especially wrt other instrumentation cases like fuel): if a code-instrumentation technique needs to interact closely with the runtime, then it makes sense to put the implementation in Wasmtime itself. For example, fuel and epoch interruption need to call special hooks (libcalls) in the runtime, and there is a certain protocol (eg for epochs, the hook returns the new epoch). In a sense, the instrumentation serves the implementation of a Wasmtime-internal feature. But here the behavior we want is just to call an external hook, so there is (i) little coupling with Wasmtime's internals, and (ii) lots of coupling with the particular needs of your instrumentation
that feels like the most important bit to me: coupling with wasmtime vs coupling with user's particular use-case
but, as fitzgen says, we could definitely discuss further in an RFC if you want to propose an API for this!
yes, that distinction makes a lot of sense
Cheng Shao has marked this topic as resolved.
Last updated: Nov 22 2024 at 16:03 UTC