cranelift: Add heap support to filetest infrastructure

[afonso360]

Hey, this is an initial version of what was discussed in #3136. The design and whether or not its a good idea are still up for debate, but I thought having an initial implementation would help visualizing how this would turn out.

The interpreter doesn't support multiple heaps yet, so we will need to alter test interpret once it does.

Closes #3136

[afonso360]

@abrown I've added some docs about this feature, would you be able to take a look?

[abrown]

I guess my biggest question here is about how we use this during fuzzing?

[abrown]

1. Should this be handling overflow?
2. And what changes here if/when cranelift: Add stack support to the interpreter with virtual addresses #3187 is merged?
3. And are we going to reuse this struct when we fuzz CLIF + heaps?

[afonso360]

Should this be handling overflow?

According to the rust docs, this should always be safe. But even in the event where this goes wrong I would expect the tests to fail with a SIGSEGV. It might be better to change to the wrapping_add variant of this function.

And what changes here if/when cranelift: Add stack support to the interpreter with virtual addresses #3187 is merged?

We won't be able to do this the same way with the interpreter, it will probably need some refactoring to handle the separate address space. Off the top of my head, I think we can do something like the following:

• Allocate the heaps as usual
• Register each heap with the interpreter
• Request the heap pointers from the interpreter
• Build the context_struct with those pointers.

And are we going to reuse this struct when we fuzz CLIF + heaps?

I hadn't thought about that, but it actually is an easy way to pass all of this info while fuzzing to the interpreter and the actual compiled target.

For fuzzing I'd like to relax the requirement that vmctx is the first argument, but that shouldn't be an issue, since we only check for that in the parser.

We may also need to coordinate the heaps with the generated global_values in each function. Otherwise I think the fuzzer may have issues generating the correct offsets to get valid heap accesses.

I think we should be OK reusing this for fuzzing, with the changes to generate the valid pointers for the interpreter.

[abrown]

I think I'm good with this; maybe rebase to make the CI failures go away?