Stream: git-wasmtime

Topic: wasmtime / Issue #1453 Rejiggering the CodeSinks for Spid...


view this post on Zulip Wasmtime GitHub notifications bot (Apr 01 2020 at 10:46):

bnjbvr opened Issue #1453:

Cranelift is used in Spidermonkey, as part of an integration called Baldrdash. In Baldrdash, we're currently barely using the RelocSink capabilities, because the information it provides us is incomplete:

  1. when tracking call relocations, we'd need to get the source loc information. This is useful for stack frame iteration, e.g. displaying the wasm bytecode offset in stack traces, when an error occurs.
  2. indirect calls don't have relocations, but Spidermonkey needs to track the call site during stack frame iteration, again (the return address is used as a key for a mapping from call sites to call metadata, including the wasm bytecode offset).
  3. stack maps in Spidermonkey are keyed by the address of the instruction following the instruction to which the stack map relates. This is because when we want to get a stack map for a call/software interrupt, we're usually in the middle of stack frame iteration, and we only have access to the return address for calls, or the address of the next value of PC for software interrupts. Currently, the StackMapSink doesn't offer the information of the next instruction's address, so we have to do something very manual for this (iterate over every instruction, if it's a safepoint remember it for the next instruction, if there was a remembered safepoint add the stackmap with the instruction+size offset to the list of stackmaps). An example may help understanding here:
; Cranelift IR
   safepoint
   call $0; for instance
   iadd
; Machine code
   ; safepoint generates nothing
   call {reloc}
   iadd ; effectively the return address of the above call, so the address we have access to when looking up a stack map for the call during stack frame iteration.

For the new backend integration, we won't be able to do this anymore, for several reasons:

My proposal is the following:

Alternatives I've considered:

I will implement my proposal locally, but I'd be happy to read what people think of it!

view this post on Zulip Wasmtime GitHub notifications bot (Apr 01 2020 at 10:46):

bnjbvr labeled Issue #1453:

Cranelift is used in Spidermonkey, as part of an integration called Baldrdash. In Baldrdash, we're currently barely using the RelocSink capabilities, because the information it provides us is incomplete:

  1. when tracking call relocations, we'd need to get the source loc information. This is useful for stack frame iteration, e.g. displaying the wasm bytecode offset in stack traces, when an error occurs.
  2. indirect calls don't have relocations, but Spidermonkey needs to track the call site during stack frame iteration, again (the return address is used as a key for a mapping from call sites to call metadata, including the wasm bytecode offset).
  3. stack maps in Spidermonkey are keyed by the address of the instruction following the instruction to which the stack map relates. This is because when we want to get a stack map for a call/software interrupt, we're usually in the middle of stack frame iteration, and we only have access to the return address for calls, or the address of the next value of PC for software interrupts. Currently, the StackMapSink doesn't offer the information of the next instruction's address, so we have to do something very manual for this (iterate over every instruction, if it's a safepoint remember it for the next instruction, if there was a remembered safepoint add the stackmap with the instruction+size offset to the list of stackmaps). An example may help understanding here:
; Cranelift IR
   safepoint
   call $0; for instance
   iadd
; Machine code
   ; safepoint generates nothing
   call {reloc}
   iadd ; effectively the return address of the above call, so the address we have access to when looking up a stack map for the call during stack frame iteration.

For the new backend integration, we won't be able to do this anymore, for several reasons:

My proposal is the following:

Alternatives I've considered:

I will implement my proposal locally, but I'd be happy to read what people think of it!

view this post on Zulip Wasmtime GitHub notifications bot (Apr 01 2020 at 10:46):

github-actions[bot] commented on Issue #1453:

Subscribe to Label Action

This issue or pull request has been labeled: "cranelift"

<details> <summary>Users Subscribed to "cranelift"</summary>

</details>

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

Learn more.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 01 2020 at 18:16):

pchickey commented on Issue #1453:

Sounds good! Thanks for writing it up.


Last updated: Dec 23 2024 at 12:05 UTC