…roperly in Pulley.

This is a followup to bytecodealliance#11895 where I had disabled a test that failed to
emit a debug event for a hostcall-generated trap on a divide-by-zero in
Pulley. This PR allows that test to pass, and brings Pulley back to
parity with native Cranelift in debug support currently.

This was a bit of a "start to pull the thread and the entire finished
mechanism materializes" PR; happy to consider ways to split it up if
needed. In short, disabling signal-based traps on a Pulley configuration
still relies on Pulley opcodes (e.g., divide) actually trapping, in a
way that looks more like a "native ISA trap"; so I had to start to build
out the actual trap-handling mechanisms. In any case, this will all be
needed for followup work soon that will handle traps on native platforms
(redirecting from signals by injecting calls), so this is not a
distraction.

This PR includes, ranked in decreasing order of "may scare other
Wasmtime maintainers" score:

- A raw `NonNull<dyn VMStore>` in the `CallThreadState`, with a long
  comment about provenance and mut-borrow exclusivity. This is needed
  right now to allow the interpreter to invoke the debug event handler,
  but will soon be needed when injecting hostcalls on signals, because a
  signal context also has no state available from the Wasm code other
  than what is in TLS. Hence, we need a way to get the store back from
  the Wasm when we do something that is "morally a hostcall" at a
  trapping instruction.

  I do believe this is sound, or at least close to it if not (please
  scrutinize carefully!); the basic idea is that the Wasm acts as an
  opaque blob in the middle, and the pointer comes out of it one way or
  another (the normal way, as the first arg to a hostcall, or the weird
  way, via TLS and the CallThreadState during a trap).
  Exclusive ownership is still clear at any given point and only one
  `&mut` ever exists in the current frame at a time. That said, I
  haven't tested with miri yet.

  This does require careful thought about the Wasm compilation, too; we
  need the moral equivalent of a `&mut self` reborrow as-if we were
  making a hostcall on each trapping instruction. It turns out that we
  already treat them as memory-fence instructions, so nothing loaded
  from the store can be moved or cached across them, and I've added a
  comment now about how this is load-bearing.

- Updates to `CallThreadState`'s "exit state", normally set by the exit
  trampoline, that we now also set when we invoke a debug event handler
  during a trap context[^1] so that `Store::debug_frames` properly sees
  the current activation. This is a little more awkward than it could be
  because we store the *tramopline* FP, not last Wasm FP, and there is
  no trampoline frame in this case, so I've added a flag and some
  conditionals. I'm happy to refactor instead to go (back) to storing
  the last Wasm FP instead, with the extra load in the exit trampoline
  to compute that.

- A whole bunch of plumbing, creating a large but mechanical diff, in
  the code translator to actually add debug tags on all traps and calls
  to `raise`. It turns out that once I got all of the above working in
  Pulley, the test disagreed about current Wasm PC between native and
  Pulley, and Pulley was right; native was getting it wrong because the
  `ud2` was sunk to the bottom in a cold block and, without tags, we
  scanned backward to pick up the last Wasm PC in the function. This new
  plumbing and addition of tags in all the appropriate places fixes
  that.

[^1]: I keep saying "during a trap context" here, but to avoid any
      signal-safety scares, note that when this is done for native
      signals in a followup PR, we will inject a hostcall by modifying
      stack/register state and returning from the actual signal context,
      so it really is as-if we did a hostcall from a trapping
      instruction.

…roperly in Pulley.

This is a followup to bytecodealliance#11895 where I had disabled a test that failed to
emit a debug event for a hostcall-generated trap on a divide-by-zero in
Pulley. This PR allows that test to pass, and brings Pulley back to
parity with native Cranelift in debug support currently.

This was a bit of a "start to pull the thread and the entire finished
mechanism materializes" PR; happy to consider ways to split it up if
needed. In short, disabling signal-based traps on a Pulley configuration
still relies on Pulley opcodes (e.g., divide) actually trapping, in a
way that looks more like a "native ISA trap"; so I had to start to build
out the actual trap-handling mechanisms. In any case, this will all be
needed for followup work soon that will handle traps on native platforms
(redirecting from signals by injecting calls), so this is not a
distraction.

This PR includes, ranked in decreasing order of "may scare other
Wasmtime maintainers" score:

- A raw `NonNull<dyn VMStore>` in the `CallThreadState`, with a long
  comment about provenance and mut-borrow exclusivity. This is needed
  right now to allow the interpreter to invoke the debug event handler,
  but will soon be needed when injecting hostcalls on signals, because a
  signal context also has no state available from the Wasm code other
  than what is in TLS. Hence, we need a way to get the store back from
  the Wasm when we do something that is "morally a hostcall" at a
  trapping instruction.

  I do believe this is sound, or at least close to it if not (please
  scrutinize carefully!); the basic idea is that the Wasm acts as an
  opaque blob in the middle, and the pointer comes out of it one way or
  another (the normal way, as the first arg to a hostcall, or the weird
  way, via TLS and the CallThreadState during a trap).
  Exclusive ownership is still clear at any given point and only one
  `&mut` ever exists in the current frame at a time. That said, I
  haven't tested with miri yet.

  This does require careful thought about the Wasm compilation, too; we
  need the moral equivalent of a `&mut self` reborrow as-if we were
  making a hostcall on each trapping instruction. It turns out that we
  already treat them as memory-fence instructions, so nothing loaded
  from the store can be moved or cached across them, and I've added a
  comment now about how this is load-bearing.

- Updates to `CallThreadState`'s "exit state", normally set by the exit
  trampoline, that we now also set when we invoke a debug event handler
  during a trap context[^1] so that `Store::debug_frames` properly sees
  the current activation. This is a little more awkward than it could be
  because we store the *tramopline* FP, not last Wasm FP, and there is
  no trampoline frame in this case, so I've added a flag and some
  conditionals. I'm happy to refactor instead to go (back) to storing
  the last Wasm FP instead, with the extra load in the exit trampoline
  to compute that.

- A whole bunch of plumbing, creating a large but mechanical diff, in
  the code translator to actually add debug tags on all traps and calls
  to `raise`. It turns out that once I got all of the above working in
  Pulley, the test disagreed about current Wasm PC between native and
  Pulley, and Pulley was right; native was getting it wrong because the
  `ud2` was sunk to the bottom in a cold block and, without tags, we
  scanned backward to pick up the last Wasm PC in the function. This new
  plumbing and addition of tags in all the appropriate places fixes
  that.

[^1]: I keep saying "during a trap context" here, but to avoid any
      signal-safety scares, note that when this is done for native
      signals in a followup PR, we will inject a hostcall by modifying
      stack/register state and returning from the actual signal context,
      so it really is as-if we did a hostcall from a trapping
      instruction.

…roperly in Pulley.

This is a followup to bytecodealliance#11895 where I had disabled a test that failed to
emit a debug event for a hostcall-generated trap on a divide-by-zero in
Pulley. This PR allows that test to pass, and brings Pulley back to
parity with native Cranelift in debug support currently.

This was a bit of a "start to pull the thread and the entire finished
mechanism materializes" PR; happy to consider ways to split it up if
needed. In short, disabling signal-based traps on a Pulley configuration
still relies on Pulley opcodes (e.g., divide) actually trapping, in a
way that looks more like a "native ISA trap"; so I had to start to build
out the actual trap-handling mechanisms. In any case, this will all be
needed for followup work soon that will handle traps on native platforms
(redirecting from signals by injecting calls), so this is not a
distraction.

This PR includes, ranked in decreasing order of "may scare other
Wasmtime maintainers" score:

- A raw `NonNull<dyn VMStore>` in the `CallThreadState`, with a long
  comment about provenance and mut-borrow exclusivity. This is needed
  right now to allow the interpreter to invoke the debug event handler,
  but will soon be needed when injecting hostcalls on signals, because a
  signal context also has no state available from the Wasm code other
  than what is in TLS. Hence, we need a way to get the store back from
  the Wasm when we do something that is "morally a hostcall" at a
  trapping instruction.

  I do believe this is sound, or at least close to it if not (please
  scrutinize carefully!); the basic idea is that the Wasm acts as an
  opaque blob in the middle, and the pointer comes out of it one way or
  another (the normal way, as the first arg to a hostcall, or the weird
  way, via TLS and the CallThreadState during a trap).
  Exclusive ownership is still clear at any given point and only one
  `&mut` ever exists in the current frame at a time. That said, I
  haven't tested with miri yet.

  This does require careful thought about the Wasm compilation, too; we
  need the moral equivalent of a `&mut self` reborrow as-if we were
  making a hostcall on each trapping instruction. It turns out that we
  already treat them as memory-fence instructions, so nothing loaded
  from the store can be moved or cached across them, and I've added a
  comment now about how this is load-bearing.

- Updates to `CallThreadState`'s "exit state", normally set by the exit
  trampoline, that we now also set when we invoke a debug event handler
  during a trap context[^1] so that `Store::debug_frames` properly sees
  the current activation. This is a little more awkward than it could be
  because we store the *tramopline* FP, not last Wasm FP, and there is
  no trampoline frame in this case, so I've added a flag and some
  conditionals. I'm happy to refactor instead to go (back) to storing
  the last Wasm FP instead, with the extra load in the exit trampoline
  to compute that.

- A whole bunch of plumbing, creating a large but mechanical diff, in
  the code translator to actually add debug tags on all traps and calls
  to `raise`. It turns out that once I got all of the above working in
  Pulley, the test disagreed about current Wasm PC between native and
  Pulley, and Pulley was right; native was getting it wrong because the
  `ud2` was sunk to the bottom in a cold block and, without tags, we
  scanned backward to pick up the last Wasm PC in the function. This new
  plumbing and addition of tags in all the appropriate places fixes
  that.

[^1]: I keep saying "during a trap context" here, but to avoid any
      signal-safety scares, note that when this is done for native
      signals in a followup PR, we will inject a hostcall by modifying
      stack/register state and returning from the actual signal context,
      so it really is as-if we did a hostcall from a trapping
      instruction.

…roperly in Pulley.

This is a followup to bytecodealliance#11895 where I had disabled a test that failed to
emit a debug event for a hostcall-generated trap on a divide-by-zero in
Pulley. This PR allows that test to pass, and brings Pulley back to
parity with native Cranelift in debug support currently.

This was a bit of a "start to pull the thread and the entire finished
mechanism materializes" PR; happy to consider ways to split it up if
needed. In short, disabling signal-based traps on a Pulley configuration
still relies on Pulley opcodes (e.g., divide) actually trapping, in a
way that looks more like a "native ISA trap"; so I had to start to build
out the actual trap-handling mechanisms. In any case, this will all be
needed for followup work soon that will handle traps on native platforms
(redirecting from signals by injecting calls), so this is not a
distraction.

This PR includes, ranked in decreasing order of "may scare other
Wasmtime maintainers" score:

- A raw `NonNull<dyn VMStore>` in the `CallThreadState`, with a long
  comment about provenance and mut-borrow exclusivity. This is needed
  right now to allow the interpreter to invoke the debug event handler,
  but will soon be needed when injecting hostcalls on signals, because a
  signal context also has no state available from the Wasm code other
  than what is in TLS. Hence, we need a way to get the store back from
  the Wasm when we do something that is "morally a hostcall" at a
  trapping instruction.

  I do believe this is sound, or at least close to it if not (please
  scrutinize carefully!); the basic idea is that the Wasm acts as an
  opaque blob in the middle, and the pointer comes out of it one way or
  another (the normal way, as the first arg to a hostcall, or the weird
  way, via TLS and the CallThreadState during a trap).
  Exclusive ownership is still clear at any given point and only one
  `&mut` ever exists in the current frame at a time. That said, I
  haven't tested with miri yet.

  This does require careful thought about the Wasm compilation, too; we
  need the moral equivalent of a `&mut self` reborrow as-if we were
  making a hostcall on each trapping instruction. It turns out that we
  already treat them as memory-fence instructions, so nothing loaded
  from the store can be moved or cached across them, and I've added a
  comment now about how this is load-bearing.

- Updates to `CallThreadState`'s "exit state", normally set by the exit
  trampoline, that we now also set when we invoke a debug event handler
  during a trap context[^1] so that `Store::debug_frames` properly sees
  the current activation. This is a little more awkward than it could be
  because we store the *trampoline* FP, not last Wasm FP, and there is
  no trampoline frame in this case, so I've added a flag and some
  conditionals. I'm happy to refactor instead to go (back) to storing
  the last Wasm FP instead, with the extra load in the exit trampoline
  to compute that.

- A whole bunch of plumbing, creating a large but mechanical diff, in
  the code translator to actually add debug tags on all traps and calls
  to `raise`. It turns out that once I got all of the above working in
  Pulley, the test disagreed about current Wasm PC between native and
  Pulley, and Pulley was right; native was getting it wrong because the
  `raise` libcall was sunk to the bottom in a cold block and, without
  tags, we scanned backward to pick up the last Wasm PC in the function.
  This new plumbing and addition of tags in all the appropriate places
  fixes that.

[^1]: I keep saying "during a trap context" here, but to avoid any
      signal-safety scares, note that when this is done for native
      signals in a followup PR, we will inject a hostcall by modifying
      stack/register state and returning from the actual signal context,
      so it really is as-if we did a hostcall from a trapping
      instruction.

…roperly in Pulley.

This is a followup to bytecodealliance#11895 where I had disabled a test that failed to
emit a debug event for a hostcall-generated trap on a divide-by-zero in
Pulley. This PR allows that test to pass, and brings Pulley back to
parity with native Cranelift in debug support currently.

This was a bit of a "start to pull the thread and the entire finished
mechanism materializes" PR; happy to consider ways to split it up if
needed. In short, disabling signal-based traps on a Pulley configuration
still relies on Pulley opcodes (e.g., divide) actually trapping, in a
way that looks more like a "native ISA trap"; so I had to start to build
out the actual trap-handling mechanisms. In any case, this will all be
needed for followup work soon that will handle traps on native platforms
(redirecting from signals by injecting calls), so this is not a
distraction.

This PR includes, ranked in decreasing order of "may scare other
Wasmtime maintainers" score:

- A raw `NonNull<dyn VMStore>` in the `CallThreadState`, with a long
  comment about provenance and mut-borrow exclusivity. This is needed
  right now to allow the interpreter to invoke the debug event handler,
  but will soon be needed when injecting hostcalls on signals, because a
  signal context also has no state available from the Wasm code other
  than what is in TLS. Hence, we need a way to get the store back from
  the Wasm when we do something that is "morally a hostcall" at a
  trapping instruction.

  I do believe this is sound, or at least close to it if not (please
  scrutinize carefully!); the basic idea is that the Wasm acts as an
  opaque blob in the middle, and the pointer comes out of it one way or
  another (the normal way, as the first arg to a hostcall, or the weird
  way, via TLS and the CallThreadState during a trap).
  Exclusive ownership is still clear at any given point and only one
  `&mut` ever exists in the current frame at a time. That said, I
  haven't tested with miri yet.

  This does require careful thought about the Wasm compilation, too; we
  need the moral equivalent of a `&mut self` reborrow as-if we were
  making a hostcall on each trapping instruction. It turns out that we
  already treat them as memory-fence instructions, so nothing loaded
  from the store can be moved or cached across them, and I've added a
  comment now about how this is load-bearing.

- Updates to `CallThreadState`'s "exit state", normally set by the exit
  trampoline, that we now also set when we invoke a debug event handler
  during a trap context[^1] so that `Store::debug_frames` properly sees
  the current activation. This is a little more awkward than it could be
  because we store the *trampoline* FP, not last Wasm FP, and there is
  no trampoline frame in this case, so I've added a flag and some
  conditionals. I'm happy to refactor instead to go (back) to storing
  the last Wasm FP instead, with the extra load in the exit trampoline
  to compute that.

- A whole bunch of plumbing, creating a large but mechanical diff, in
  the code translator to actually add debug tags on all traps and calls
  to `raise`. It turns out that once I got all of the above working in
  Pulley, the test disagreed about current Wasm PC between native and
  Pulley, and Pulley was right; native was getting it wrong because the
  `raise` libcall was sunk to the bottom in a cold block and, without
  tags, we scanned backward to pick up the last Wasm PC in the function.
  This new plumbing and addition of tags in all the appropriate places
  fixes that.

[^1]: I keep saying "during a trap context" here, but to avoid any
      signal-safety scares, note that when this is done for native
      signals in a followup PR, we will inject a hostcall by modifying
      stack/register state and returning from the actual signal context,
      so it really is as-if we did a hostcall from a trapping
      instruction.