Add core dump support to the runtime

[itsrainy]

This adds a configuration option and machinery to capture a core dump when
a trap occurs and attach it to the resulting anyhow::Error that gets bubbled up to
the caller. I've created a CoreDumpStack structure in the runtime, which is
currently just a backtrace until we design a way to recover the locals and
stack values when a trap occurs. When that CoreDumpStack gets converted to
a wasmtime::WasmCoreDump, we add additional information from the Store such
as globals, memories, and instance information.

A lot of this is mechanistically similar to how backtraces
are captured and attached to errors. Given that they both are attached as
context to anyhow::Errors, setting coredump_on_trap to true will supersede
any setting for wasm_backtrace.

[github-actions]

Subscribe to Label Action

cc @peterhuene

This issue or pull request has been labeled: "wasmtime:api", "wasmtime:config"

Thus the following users have been cc'd because of the following labels:

• peterhuene: wasmtime:api

To subscribe or unsubscribe from this label, edit the .github/subscribe-to-label.json configuration file.

Learn more.

[github-actions]

Label Messager: wasmtime:config

It looks like you are changing Wasmtime's configuration options. Make sure to
complete this check list:

• If you added a new Config method, you wrote extensive documentation for
  it.

  Our documentation should be of the following form:

  Short, simple summary sentence.
  
  More details. These details can be multiple paragraphs. There should be
  information about not just the method, but its parameters and results as
  well.
  
  Is this method fallible? If so, when can it return an error?
  
  Can this method panic? If so, when does it panic?
  
  # Example
  
  Optional example here.
  

• If you added a new Config method, or modified an existing one, you
  ensured that this configuration is exercised by the fuzz targets.

  For example, if you expose a new strategy for allocating the next instance
  slot inside the pooling allocator, you should ensure that at least one of our
  fuzz targets exercises that new strategy.

  Often, all that is required of you is to ensure that there is a knob for this
  configuration option in wasmtime_fuzzing::Config (or one
  of its nested structs).

  Rarely, this may require authoring a new fuzz target to specifically test this
  configuration. See our docs on fuzzing for more details.

• If you are enabling a configuration option by default, make sure that it
  has been fuzzed for at least two weeks before turning it on by default.

---

To modify this label's message, edit the .github/label-messager/wasmtime-config.md file.

To add new label messages or remove existing label messages, edit the
.github/label-messager.json configuration file.

Learn more.

[fitzgen]

This is looking good!

Before this can land, we still need some smoke tests under tests/all/coredump.rs though. Should test that we get the expected stack, modules, instances, globals, and memories in the resulting coredumps.

To be explicit, mostly for folks following along at home, I'm okay with waiting for follow up PRs to implement

• serialization into the Wasm coredump format for wastime::WasmCoreDump
• implementing wasmtime --coredump-on-trap=... in the CLI on top of wasmtime::WasmCoreDump.

A few nitpicks inline below.

Thanks!

[itsrainy]

@fitzgen I added some smoke tests though I am still trying to figure out why exported Globals and Memories aren't getting included in the CoreDump.

Also in order to downcast the anyhow error to a WasmCoreDump, it needs to #[derive(Debug)]. To make that work I switched the Vec<Module> on the WasmCoreDump to be a vec of just the module names for now. Otherwise it seems like I would have to add #[derive(Debug)] to a whole bunch of things (Module, ModuleInner, Engine, EngineInner, Config, etc) which seemed a bit wide-sweeping.

[fitzgen]

Also in order to downcast the anyhow error to a WasmCoreDump, it needs to #[derive(Debug)]. To make that work I switched the Vec<Module> on the WasmCoreDump to be a vec of just the module names for now. Otherwise it seems like I would have to add #[derive(Debug)] to a whole bunch of things (Module, ModuleInner, Engine, EngineInner, Config, etc) which seemed a bit wide-sweeping.

Ah, I think it would actually be better to make a custom Debug impl for WasmCoreDump than to derive(Debug) in this case. We can start with something like the following, and update it with useful diagnostic information over time as needed.

impl std::fmt::Debug for WasmCoreDump {
    fn fmt(&self, f: &mut std::fmt::Formatter) -> std::fmt::Result {
        write!(f, "<wasm core dump>")
    }
}

This avoids needing to do derive(Debug) on Module or anything like that and lets us continue to hold onto the modules inside WasmCoreDump.

[fitzgen]

LGTM! Feel free to enqueue to merge when this is rebased and conflicts are resolved.