Stream: git-wasmtime

Topic: wasmtime / Issue #2738 No way to access stackmaps using c...

Wasmtime GitHub notifications bot (Mar 18 2021 at 16:23):

wrbs opened Issue #2738:

In #1184 and #1214 cranelift-module was extended to add support for passing in a trap sink while compiling a function. However there's no support for doing the same with a StackMapSink and it looks like at the time this was deferred to later.

I'm interested in using the GC support for something which would use the cranelift-jit interface but there's currently no way to access stackmaps when doing that.

I'm not sure what the best way to fix this is. One method could be adding a stack_map_sink: &mut dyn StackMapSink argument to define_function but that would require all users of the interface (most of who don't use stack maps) to pass in a &mut NullStackMapSink {} in the same way as passing a NullTrapSink is required. However if breaking changes to the API are ok this fits the existing convention.

I'm thinking of sending a PR with this approach but I'd like to know if this is acceptable.

Wasmtime GitHub notifications bot (Mar 18 2021 at 16:26):

pchickey commented on Issue #2738:

That sounds like a fine approach - please do send a PR!

Wasmtime GitHub notifications bot (Mar 19 2021 at 00:49):

pchickey closed Issue #2738:

In #1184 and #1214 cranelift-module was extended to add support for passing in a trap sink while compiling a function. However there's no support for doing the same with a StackMapSink and it looks like at the time this was deferred to later.

I'm interested in using the GC support for something which would use the cranelift-jit interface but there's currently no way to access stackmaps when doing that.

I'm not sure what the best way to fix this is. One method could be adding a stack_map_sink: &mut dyn StackMapSink argument to define_function but that would require all users of the interface (most of who don't use stack maps) to pass in a &mut NullStackMapSink {} in the same way as passing a NullTrapSink is required. However if breaking changes to the API are ok this fits the existing convention.

I'm thinking of sending a PR with this approach but I'd like to know if this is acceptable.

Last updated: Dec 13 2025 at 19:03 UTC