philipc commented on Issue #1214:
My intent in https://github.com/bytecodealliance/wasmtime/issues/1184#issuecomment-590618409 was that the backends would no longer store traps at all. e.g. the caller would pass a
binemit::TrapSink
toModule::define_function
(or a new variant of that), andModule::define_function_bytes
would no longer need to know about traps. But it's not something that I strongly feel needs to change if you think it's better to keep storing them in the backend.
froydnj commented on Issue #1214:
My intent in #1184 (comment) was that the backends would no longer store traps at all. e.g. the caller would pass a
binemit::TrapSink
toModule::define_function
(or a new variant of that), andModule::define_function_bytes
would no longer need to know about traps. But it's not something that I strongly feel needs to change if you think it's better to keep storing them in the backend.Ah, I didn't fully grok what you were saying there; thank you for the additional clarification!
I think passing in
binemit::TrapSink
would be slightly cleaner, but that implies that traps are somehow more important than relocs or stackmaps, and I'm not clear on why that'd be true. I guess you can argue that the backend should be responsible for applying relocations on its own, and nobody seems to (currently) do anything with stackmaps anyway (at least in the context ofcranelift-module
)?In the absence of strong feelings, I am inclined to leave the patch as-is.
pchickey commented on Issue #1214:
I agree that relocations are something we just give the backend.
We'll have to do something with stackmaps in
cranelift-module
eventually, the lack of pressure is because they are used for GC, which only wasmtime is going to implement, and wasmtime isnt using cranelift-module yet. There's a reasonable argument that whatever design we pick for traps, we should use for stack maps as well, for the sake of consistency. Passing in a sink for traps and stackmaps gives the consumer more control than returning a vector, so I'm in favor of that design, if we're going to revise.I'm also ok with landing this as-is and revising it later, speaking as a downstream. Its not a huge difference to us either way, so I'll defer to bjorn and philipc.
philipc commented on Issue #1214:
Yeah this is ok as-is.
pchickey commented on Issue #1214:
Lets get @tschneidereit to add you as a collab so you can merge these when they're ready to go
tschneidereit commented on Issue #1214:
Lets get @tschneidereit to add you as a collab so you can merge these when they're ready to go
Agreed!
Last updated: Nov 22 2024 at 16:03 UTC