Implement AOT compilation for components (#5160)

* Pull `Module` out of `ModuleTextBuilder`

This commit is the first in what will likely be a number towards
preparing for serializing a compiled component to bytes, a precompiled
artifact. To that end my rough plan is to merge all of the compiled
artifacts for a component into one large object file instead of having
lots of separate object files and lots of separate mmaps to manage. To
that end I plan on eventually using `ModuleTextBuilder` to build one
large text section for all core wasm modules and trampolines, meaning
that `ModuleTextBuilder` is no longer specific to one module. I've
extracted out functionality such as function name calculation as well as
relocation resolving (now a closure passed in) in preparation for this.

For now this just keeps tests passing, and the trajectory for this
should become more clear over the following commits.

* Remove component-specific object emission

This commit removes the `ComponentCompiler::emit_obj` function in favor
of `Compiler::emit_obj`, now renamed `append_code`. This involved
significantly refactoring code emission to take a flat list of functions
into `append_code` and the caller is responsible for weaving together
various "families" of functions and un-weaving them afterwards.

* Consolidate ELF parsing in `CodeMemory`

This commit moves the ELF file parsing and section iteration from
`CompiledModule` into `CodeMemory` so one location keeps track of
section ranges and such. This is in preparation for sharing much of this
code with components which needs all the same sections to get tracked
but won't be using `CompiledModule`. A small side benefit from this is
that the section parsing done in `CodeMemory` and `CompiledModule` is no
longer duplicated.

* Remove separately tracked traps in components

Previously components would generate an "always trapping" function
and the metadata around which pc was allowed to trap was handled
manually for components. With recent refactorings the Wasmtime-standard
trap section in object files is now being generated for components as
well which means that can be reused instead of custom-tracking this
metadata. This commit removes the manual tracking for the `always_trap`
functions and plumbs the necessary bits around to make components look
more like modules.

* Remove a now-unnecessary `Arc` in `Module`

Not expected to have any measurable impact on performance, but
complexity-wise this should make it a bit easier to understand the
internals since there's no longer any need to store this somewhere else
than its owner's location.

* Merge compilation artifacts of components

This commit is a large refactoring of the component compilation process
to produce a single artifact instead of multiple binary artifacts. The
core wasm compilation process is refactored as well to share as much
code as necessary with the component compilation process.

This method of representing a compiled component necessitated a few
medium-sized changes internally within Wasmtime:

* A new data structure was created, `CodeObject`, which represents
  metadata about a single compiled artifact. This is then stored as an
  `Arc` within a component and a module. For `Module` this is always
  uniquely owned and represents a shuffling around of data from one
  owner to another. For a `Component`, however, this is shared amongst
  all loaded modules and the top-level component.

* The "module registry" which is used for symbolicating backtraces and
  for trap information has been updated to account for a single region
  of loaded code holding possibly multiple modules. This involved adding
  a second-level `BTreeMap` for now. This will likely slow down
  instantiation slightly but if it poses an issue in the future this
  should be able to be represented with a more clever data structure.

This commit additionally solves a number of longstanding issues with
components such as compiling only one host-to-wasm trampoline per
signature instead of possibly once-per-module. Additionally the
`SignatureCollection` registration now happens once-per-component
instead of once-per-module-within-a-component.

* Fix compile errors from prior commits

* Support AOT-compiling components

This commit adds support for AOT-compiled components in the same manner
as `Module`, specifically adding:

* `Engine::precompile_component`
* `Component::serialize`
* `Component::deserialize`
* `Component::deserialize_file`

Internally the support for components looks quite similar to `Module`.
All the prior commits to this made adding the support here
(unsurprisingly) easy. Components are represented as a single object
file as are modules, and the functions for each module are all piled
into the same object file next to each other (as are areas such as data
sections). Support was also added here to quickly differentiate compiled
components vs compiled modules via the `e_flags` field in the ELF
header.

* Prevent serializing exported modules on components

The current representation of a module within a component means that the
implementation of `Module::serialize` will not work if the module is
exported from a component. The reason for this is that `serialize`
doesn't actually do anything and simply returns the underlying mmap as a
list of bytes. The mmap, however, has `.wasmtime.info` describing
component metadata as opposed to this module's metadata. While rewriting
this section could be implemented it's not so easy to do so and is
otherwise seen as not super important of a feature right now anyway.

* Fix windows build

* Fix an unused function warning

* Update crates/environ/src/compilation.rs

Co-authored-by: Nick Fitzgerald <fitzgen@gmail.com>

Co-authored-by: Nick Fitzgerald <fitzgen@gmail.com>

crates/environ/src/obj.rs

@@ -1,33 +1,121 @@
 //! Utilities for working with object files that operate as Wasmtime's
 //! serialization and intermediate format for compiled modules.
 
-use crate::{EntityRef, FuncIndex, SignatureIndex};
+/// Filler for the `os_abi` field of the ELF header.
+///
+/// This is just a constant that seems reasonable in the sense it's unlikely to
+/// clash with others.
+pub const ELFOSABI_WASMTIME: u8 = 200;
 
-const FUNCTION_PREFIX: &str = "_wasm_function_";
-const TRAMPOLINE_PREFIX: &str = "_trampoline_";
+/// Flag for the `e_flags` field in the ELF header indicating a compiled
+/// module.
+pub const EF_WASMTIME_MODULE: u32 = 1 << 0;
 
-/// Returns the symbol name in an object file for the corresponding wasm
-/// function index in a module.
-pub fn func_symbol_name(index: FuncIndex) -> String {
-    format!("{}{}", FUNCTION_PREFIX, index.index())
-}
+/// Flag for the `e_flags` field in the ELF header indicating a compiled
+/// component.
+pub const EF_WASMTIME_COMPONENT: u32 = 1 << 1;
 
-/// Attempts to extract the corresponding function index from a symbol possibly produced by
-/// `func_symbol_name`.
-pub fn try_parse_func_name(name: &str) -> Option<FuncIndex> {
-    let n = name.strip_prefix(FUNCTION_PREFIX)?.parse().ok()?;
-    Some(FuncIndex::new(n))
-}
+/// A custom Wasmtime-specific section of our compilation image which stores
+/// mapping data from offsets in the image to offset in the original wasm
+/// binary.
+///
+/// This section has a custom binary encoding. Currently its encoding is:
+///
+/// * The section starts with a 32-bit little-endian integer. This integer is
+///   how many entries are in the following two arrays.
+/// * Next is an array with the previous count number of 32-bit little-endian
+///   integers. This array is a sorted list of relative offsets within the text
+///   section. This is intended to be a lookup array to perform a binary search
+///   on an offset within the text section on this array.
+/// * Finally there is another array, with the same count as before, also of
+///   32-bit little-endian integers. These integers map 1:1 with the previous
+///   array of offsets, and correspond to what the original offset was in the
+///   wasm file.
+///
+/// Decoding this section is intentionally simple, it only requires loading a
+/// 32-bit little-endian integer plus some bounds checks. Reading this section
+/// is done with the `lookup_file_pos` function below. Reading involves
+/// performing a binary search on the first array using the index found for the
+/// native code offset to index into the second array and find the wasm code
+/// offset.
+///
+/// At this time this section has an alignment of 1, which means all reads of it
+/// are unaligned. Additionally at this time the 32-bit encodings chosen here
+/// mean that >=4gb text sections are not supported.
+pub const ELF_WASMTIME_ADDRMAP: &str = ".wasmtime.addrmap";
 
-/// Returns the symbol name in an object file for the corresponding trampoline
-/// for the given signature in a module.
-pub fn trampoline_symbol_name(index: SignatureIndex) -> String {
-    format!("{}{}", TRAMPOLINE_PREFIX, index.index())
-}
+/// A custom binary-encoded section of wasmtime compilation artifacts which
+/// encodes the ability to map an offset in the text section to the trap code
+/// that it corresponds to.
+///
+/// This section is used at runtime to determine what flavor fo trap happened to
+/// ensure that embedders and debuggers know the reason for the wasm trap. The
+/// encoding of this section is custom to Wasmtime and managed with helpers in
+/// the `object` crate:
+///
+/// * First the section has a 32-bit little endian integer indicating how many
+///   trap entries are in the section.
+/// * Next is an array, of the same length as read before, of 32-bit
+///   little-endian integers. These integers are offsets into the text section
+///   of the compilation image.
+/// * Finally is the same count number of bytes. Each of these bytes corresponds
+///   to a trap code.
+///
+/// This section is decoded by `lookup_trap_code` below which will read the
+/// section count, slice some bytes to get the various arrays, and then perform
+/// a binary search on the offsets array to find the an index corresponding to
+/// the pc being looked up. If found the same index in the trap array (the array
+/// of bytes) is the trap code for that offset.
+///
+/// Note that at this time this section has an alignment of 1. Additionally due
+/// to the 32-bit encodings for offsets this doesn't support images >=4gb.
+pub const ELF_WASMTIME_TRAPS: &str = ".wasmtime.traps";
 
-/// Attempts to extract the corresponding signature index from a symbol
-/// possibly produced by `trampoline_symbol_name`.
-pub fn try_parse_trampoline_name(name: &str) -> Option<SignatureIndex> {
-    let n = name.strip_prefix(TRAMPOLINE_PREFIX)?.parse().ok()?;
-    Some(SignatureIndex::new(n))
-}
+/// A custom section which consists of just 1 byte which is either 0 or 1 as to
+/// whether BTI is enabled.
+pub const ELF_WASM_BTI: &str = ".wasmtime.bti";
+
+/// A bincode-encoded section containing engine-specific metadata used to
+/// double-check that an artifact can be loaded into the current host.
+pub const ELF_WASM_ENGINE: &str = ".wasmtime.engine";
+
+/// This is the name of the section in the final ELF image which contains
+/// concatenated data segments from the original wasm module.
+///
+/// This section is simply a list of bytes and ranges into this section are
+/// stored within a `Module` for each data segment. Memory initialization and
+/// passive segment management all index data directly located in this section.
+///
+/// Note that this implementation does not afford any method of leveraging the
+/// `data.drop` instruction to actually release the data back to the OS. The
+/// data section is simply always present in the ELF image. If we wanted to
+/// release the data it's probably best to figure out what the best
+/// implementation is for it at the time given a particular set of constraints.
+pub const ELF_WASM_DATA: &'static str = ".rodata.wasm";
+
+/// This is the name of the section in the final ELF image which contains a
+/// `bincode`-encoded `CompiledModuleInfo`.
+///
+/// This section is optionally decoded in `CompiledModule::from_artifacts`
+/// depending on whether or not a `CompiledModuleInfo` is already available. In
+/// cases like `Module::new` where compilation directly leads into consumption,
+/// it's available. In cases like `Module::deserialize` this section must be
+/// decoded to get all the relevant information.
+pub const ELF_WASMTIME_INFO: &'static str = ".wasmtime.info";
+
+/// This is the name of the section in the final ELF image which contains a
+/// concatenated list of all function names.
+///
+/// This section is optionally included in the final artifact depending on
+/// whether the wasm module has any name data at all (or in the future if we add
+/// an option to not preserve name data). This section is a concatenated list of
+/// strings where `CompiledModuleInfo::func_names` stores offsets/lengths into
+/// this section.
+///
+/// Note that the goal of this section is to avoid having to decode names at
+/// module-load time if we can. Names are typically only used for debugging or
+/// things like backtraces so there's no need to eagerly load all of them. By
+/// storing the data in a separate section the hope is that the data, which is
+/// sometimes quite large (3MB seen for spidermonkey-compiled-to-wasm), can be
+/// paged in lazily from an mmap and is never paged in if we never reference it.
+pub const ELF_NAME_DATA: &'static str = ".name.wasm";