This commit is a slight refactoring of the `Module` trait and backend in
`cranelift-object`. The goal is to enable parallelization of compilation
when using `cranelift-object`. Currently this is difficult because
`ObjectModule::define_function` requires `&mut self`. This instead
soups up the `define_function_bytes` interface to handle relocations so
compilation can happen externally before defining it in a `Module`. This
also means that `define_function` is now a convenience wrapper around
`define_function_bytes`.
Experience with the `define_function` API has shown that returning
borrowed slices of `TrapSite` is not ideal: the returned slice
represents a borrow on the entire `Module`, which makes calling back
into methods taking `&mut self` a bit tricky.
To eliminate the problem, let's require the callers of `define_function`
to provide `TrapSink` instances. This style of API enables them to
control when and how traps are collected, and makes the `object` and
`faerie` backends simpler/more efficient by not having to worry about
trap collection.
This allows us to retain richer information from backend errors.
We already have `anyhow` as a dep in several places in the wasmtime
tree, and in cranelift-faerie. faerie is the only user of this
variant.
Existing code that puts a String into the Backend error can trivially
adapt their code to emit an anyhow::Error.
The current interface of `cranelift-module` requires consumers who want
to be informed about traps to discover that information through
`Module::Product`, which is backend-specific. Since it's advantageous
to manipulate this information in a backend-agnostic way, this patch
changes `Module::define_function{,_bytes}` to return information about
the traps contained in the function being defined.
* move trap site definitions into cranelift-module
`cranelift-faerie` and `cranelift-object` already have identical
definitions of structures to represent trap sites. We might as well
merge them ahead of work to define functions via a raw slice of bytes
with associated traps, which will need some kind of common structure for
representing traps anyway.
* cranelift-module: add `define_function_bytes` interface
This interface is useful when the client needs to precisely specify the
ordering of bytes in a particular function.
* add comment about saving files for `perf`
This removes the need to call `finalize_definitions` for cranelift-object.
`finalize_definitions` is only intended for backends that produce
finalized functions and data objects, which cranelift-object does not.
The failure crate invents its own traits that don't use
std::error::Error (because failure predates certain features added to
Error); this prevents using ? on an error from failure in a function
using Error. The thiserror crate integrates with the standard Error
trait instead.
The result of the emitter is a vector of bytes holding machine code,
jump tables, and (in the future) other read-only data. Some clients,
notably Firefox's Wasm compiler, needs to separate the machine code
from the data in order to insert more code directly after the code
generated by Cranelift.
To make such separation possible, we record more information about the
emitted bytes: the sizes of each of the sections of code, jump tables,
and read-only data, as well as the locations within the code that
reference (PC-relatively) the jump tables and read-only data.
