Stream: wasi

Topic: capabilities vs debugging


view this post on Zulip Dan Gohman (Feb 24 2020 at 14:35):

https://github.com/wasm3/wasm-trace

Instruments wasm files and traces execution, using Binaryen.js and Wasmer.js - wasm3/wasm-trace

view this post on Zulip Dan Gohman (Feb 24 2020 at 14:35):

Is a fun tool, and I'm considering asking the authors if they want to add the import API to WASI

view this post on Zulip Dan Gohman (Feb 24 2020 at 14:36):

However, the trace functions don't have handles, which would make tracing an "ambient authority", in capability lingo

view this post on Zulip Dan Gohman (Feb 24 2020 at 14:37):

I'm contemplating whether or not this is something that matters here.

view this post on Zulip Dan Gohman (Feb 24 2020 at 14:41):

Requiring a handle would be a hassle here. And arguably, these trace functions are relatively inert -- we could define the behavior such that implementations could choose to implement all the functions as no-ops.

view this post on Zulip Dan Gohman (Feb 24 2020 at 14:48):

How crazy would it be to say that some APIs in WASI are "debugging" APIs, which are expected to be no-ops in any default or production setting, but which may emit tracing or other debugging things under a flag? And therefore ambient authorities are ok there?

view this post on Zulip Dan Gohman (Feb 24 2020 at 14:48):

Or maybe instead of no-ops, they'd fail to link in default/production settings.

view this post on Zulip Jakub Konka (Feb 24 2020 at 14:52):

In my very limited experience with this, I think that having debugging "superpowers" sounds OK.

view this post on Zulip Jakub Konka (Feb 24 2020 at 14:53):

In fact, I reckon it would be desirable when developing any nontrivial WASI app. You know, quicker prototyping, etc.

view this post on Zulip Josh Triplett (Feb 24 2020 at 15:53):

I have had some experience with "anyone can print" APIs, and I've found it a little annoying that I can't remove that ability from parts of the code.

view this post on Zulip Josh Triplett (Feb 24 2020 at 15:54):

I'm not arguing hard against it, but consider (for instance) whether you want that ambient authority to extend to a piece of code that's intentionally being disruptive towards debugging?

view this post on Zulip Josh Triplett (Feb 24 2020 at 15:55):

At the very least, a module might want to control whether those functions are available to another module.

view this post on Zulip Josh Triplett (Feb 24 2020 at 15:55):

(Or, for that matter, substitute in its own versions.)

view this post on Zulip Josh Triplett (Feb 24 2020 at 16:03):

Nobody should be able to just pull the "real" debugging function out of thin air without obtaining it by the linking process.

view this post on Zulip fitzgen (he/him) (Feb 24 2020 at 17:19):

if we were to do this, probably good to not expose stdout/stderr to everyone, but instead some kind of dedicated debug logging streams. some programs (cough RLS cough) communicate via a protocol over stdout and any errant printing can break the whole program

also, fwiw:

instrumenting wasm binaries to trace function execution - sliminality/wasm-trace
Brain dump of an instrumentation-based wasm tracing tool. - wasm-tracing.md

view this post on Zulip Dan Gohman (Feb 24 2020 at 17:40):

Yeah, making these dedicated imports makes sense, so that applications can do interposition to control what they do, and so that implementations can safely keep them separate from stdout/stderr.

view this post on Zulip fitzgen (he/him) (Feb 24 2020 at 17:42):

another thing is, what benefit do we get by standardizing them vs implementing support for wasmtime --trace or something directly in the engine?

view this post on Zulip fitzgen (he/him) (Feb 24 2020 at 17:42):

that would allow us to side step the question of ambient authority, and also have something similar to RUST_LOG where you can turn various tracing things on/off at the level of different wasm modules

view this post on Zulip Dan Gohman (Feb 24 2020 at 17:49):

I think it comes down to developer UI. As a developer, do you want a wasmtime command-line API way to enable tracaing, or a tooling way to enable tracing?

view this post on Zulip fitzgen (he/him) (Feb 24 2020 at 17:58):

yeah, points to be made each way.

fwiw, I think the trade off is different depending on the use case and particulars of the debugging APIs

for example, if we are tracing particular Wasm semantics level events, it doesn't make sense to let the user modify them because they can only mess it up. either they use a tool that does it correctly or the engine does it correctly. tracing things like memory.grows would fall into this bucket. I would argue that tracing these should probably be built into the engine.

but for tracing app- or module-specific custom events, it makes sense to have a custom imported tracing function. I think such an imported tracing function makes sense at a WASI level.

As a developer, do you want a wasmtime command-line API way to enable tracaing, or a tooling way to enable tracing?

Adding --trace to something I'm already using seems a lot easier to me, than adding and configuring a whole 'nother tool to my build...

Of course, this is just for wasi outside the web. on the web, you'll need another tool and some associated JS, unless browser devtools build this kind of thing in


Last updated: Dec 23 2024 at 12:05 UTC