Stream: git-wasmtime

Topic: wasmtime / issue #6298 winch: Handle relocations and traps

view this post on Zulip Wasmtime GitHub notifications bot (Apr 27 2023 at 17:49):

saulecabrera commented on issue #6298:

@alexcrichton I'd like to get your thoughts on the direction of this change, mainly around the refactoring and sharing of CompiledFunction, given the ideas and thoughts that you've shared in https://github.com/bytecodealliance/wasmtime/pull/5944.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 27 2023 at 18:44):

github-actions[bot] commented on issue #6298:

Subscribe to Label Action

cc @saulecabrera

<details>
This issue or pull request has been labeled: "winch"

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

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

Learn more.
</details>

view this post on Zulip Wasmtime GitHub notifications bot (May 02 2023 at 17:18):

saulecabrera commented on issue #6298:

@alexcrichton I think this is ready for another pass taking into account the feedback that you provided in https://github.com/bytecodealliance/wasmtime/pull/6298#discussion_r1179603816. Unfortunately this change doesn't fulfill your vision entirely; but I was able to considerably move the needle in that direction I think. In practice the traps and relocations can be easily deferred until the append_code step, but I couldn't find a way to do the same with the address_map and unwind_info without the need of a deeper refactoring (which I didn't get into), given that these fields are used in multiple places (append_code + append_dwarf) which requires either calculating them at the very beginning or finding a way to cache them after they are first calculated to be able to reuse them in later steps, which I think is doable but it might increase the scope of this PR further than what I had hoped for, but I think that with a couple more iterations we can get there in follow-up PRs. One thing to note is that I'm not passing a &MachBufferFinalized<Final> to the builder functions, as initially suggested, but instead I'm passing a &CompiledFunction which wraps the buffer and contains all the metadata needed to derive the information at each step.

Let me know your thoughts; I'm also happy to revert to the previous state in case you'd prefer to have the fully fleshed out approach as part of this change.

Last updated: Nov 22 2024 at 16:03 UTC