Dan Gohman (Feb 24 2020 at 14:35): Dan Gohman (Feb 24 2020 at 14:35):https://github.com/wasm3/wasm-trace
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
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
Dan Gohman (Feb 24 2020 at 14:37):I'm contemplating whether or not this is something that matters here.
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.
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?
Dan Gohman (Feb 24 2020 at 14:48):Or maybe instead of no-ops, they'd fail to link in default/production settings.
Jakub Konka (Feb 24 2020 at 14:52):In my very limited experience with this, I think that having debugging "superpowers" sounds OK.
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.
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.
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?
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.
Josh Triplett (Feb 24 2020 at 15:55):(Or, for that matter, substitute in its own versions.)
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.
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:
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.
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?
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
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?
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: Nov 22 2024 at 17:03 UTC