wasmtime / Issue #1184 add cranelift-module interface for... · git-wasmtime

Stream: git-wasmtime

Topic: wasmtime / Issue #1184 add cranelift-module interface for...

Wasmtime GitHub notifications bot (Feb 03 2021 at 18:26):

Since #1389 define_function gets a TrapSink argument.

Wasmtime GitHub notifications bot (Feb 03 2021 at 18:56):

Feature

lucetc needs some way of accessing the trap sites for every function it compiles:

https://github.com/bytecodealliance/lucet/blob/23305e5d8e08bed442c244d282b1a0389ed3d822/lucetc/src/output.rs#L69-L89

In the above snippet, the trap site access happens after Module::finish has been called, so we're working with faerie interfaces.

We are trying to port lucetc to use object instead of faerie underneath, mostly so lucetc can start generating PE/COFF objects with ease. It would reduce risk somewhat to be able to use cranelift-module as a high-level interface, swap between cranelift-object and cranelift-faerie with as few lines of code as possible, and deal with object and faerie themselves as little as possible (probably just to write out the .o file). Therefore, it would be convenient if this information about traps associated with each function were accessible through cranelift-module interfaces, rather than through lower-level interfaces.

Benefit

Trap information would be more easily accessible prior to module finalization. Though I don't know of anybody else who needs this kind of information about besides lucetc at this point.

Implementation

This is the tricky bit, because the three in-tree implementations differ substantially in their approach to trap collection:

cranelift-faerie collects essentially (string-name, Vec<TrapSite>) pairs.

cranelift-object collects a mapping of FuncId to Vec<TrapSite>.

cranelift-simplejit ignores traps entirely.

I don't think there is a single method that all three interfaces could easily implement to iterate over (string-name, &Vec<TrapSite>) pairs. To implement such an interface, cranelift-object would need to have a way to map from FuncId to string-name, and that's awkward to do, given that object itself doesn't deal with symbol names as strings, but as Vec<u8>.

The alternative, iterating over (FuncId, &Vec<TrapSite>) pairs, would require some kind of modification to cranelift-faerie. We could change cranelift-faerie to map from string-name to FuncId: cranelift-faerie could grow a separate table for storing that mapping, but cranelift-module is already storing that mapping, and requiring cranelift-faerie to store it seems like wasted effort. Alternatively, the way cranelift-faerie stores its traps could be modified to look more like cranelift-object.

But then maybe the right thing to do is just moving trap collection into cranelift-module itself? Module::new would then grow a flag for indicating whether trap collection should be done. Module itself would probably contain a FuncId to Vec<TrapSite> mapping similar to cranelift-object, and then Backend::define_function would receive Option<&mut Vec<TrapSite>> for potentially accumulating traps.

Since cranelift-simplejit doesn't collect traps, it doesn't matter too much what interface gets decided on.

I think I prefer moving trap collection into cranelift-module itself, but modifying cranelift-faerie to make it more like cranelift-object and the implementing some sort of common iterator interface works, too.

Alternatives

The alternative is to keep the status quo, and lucetc would need to write two sets of code for defining certain pieces of information: one that defines those pieces with faerie and another that defines them with object.

Last updated: Dec 13 2025 at 19:03 UTC