Wasmtime GitHub notifications bot (Apr 03 2020 at 21:00): Wasmtime GitHub notifications bot (Apr 03 2020 at 21:00):github-actions[bot] commented on Issue #1466:
Subscribe to Label Action
This issue or pull request has been labeled: "cranelift", "wasmtime:api"
<details> <summary>Users Subscribed to "cranelift"</summary>
- @bnjbvr
</details>
<details> <summary>Users Subscribed to "wasmtime:api"</summary>
- @peterhuene
</details>
To subscribe or unsubscribe from this label, edit the <code>.github/subscribe-to-label.json</code> configuration file.
Wasmtime GitHub notifications bot (Apr 03 2020 at 21:05):peterhuene commented on Issue #1466:
Let me fix the lightbeam build failure.
Wasmtime GitHub notifications bot (Apr 03 2020 at 21:28):peterhuene deleted a comment on Issue #1466:
Let me fix the lightbeam build failure.
Wasmtime GitHub notifications bot (Apr 03 2020 at 21:28):peterhuene commented on Issue #1466:
Refactoring to fix the arm64 build error in the file test utility.
Wasmtime GitHub notifications bot (Apr 06 2020 at 18:31):peterhuene commented on Issue #1466:
As this will conflict with #1216 (it adds additional unwind information on Windows for FPR restores), this will need to wait until #1216 goes in then I'll merge the changes.
Wasmtime GitHub notifications bot (Apr 10 2020 at 23:16):peterhuene commented on Issue #1466:
This will need some additional changes with recently merged PRs to get working again. I'll see to it on Monday.
Wasmtime GitHub notifications bot (Apr 13 2020 at 23:27):peterhuene commented on Issue #1466:
This should now be ready for review again after merging in the FPR changes for Windows unwind information.
Wasmtime GitHub notifications bot (Apr 15 2020 at 23:35):peterhuene commented on Issue #1466:
I'll see about implementing
__register_frame_tableon platforms where it can be used so we only call it once. On platforms where we can't use it, we'll walk the table registering each entry like we're doing now.
Wasmtime GitHub notifications bot (Apr 16 2020 at 09:13):bnjbvr commented on Issue #1466:
(Redirecting to @yurydelendik who seemed to have a first look already; please let me know if I need to look at this as well!)
Wasmtime GitHub notifications bot (Apr 16 2020 at 09:13):bnjbvr edited a comment on Issue #1466:
(Redirecting review to @yurydelendik who seemed to have a first look already; please let me know if I need to look at this as well!)
Wasmtime GitHub notifications bot (Apr 16 2020 at 18:07):peterhuene commented on Issue #1466:
@yurydelendik is it required around
__deregister_framethough? In the non-macOS case, we only register the entire frame table once and deregister once because only one element was added to theregistrationsvec.
Wasmtime GitHub notifications bot (Apr 16 2020 at 18:33):yurydelendik commented on Issue #1466:
@yurydelendik is it required around __deregister_frame though?
Good question. I would expect the api the by "symmetrical", means that if whatever is fed to __register_frame shall be passed to __deregister_frame. (FWIW this hole API and confusing)
Is it possible to check if 1) the current __deregister_frame code de-registers FDEs; 2) does not add addition O(n^2) complexity for gcc unwind ?
Wasmtime GitHub notifications bot (Apr 16 2020 at 18:33):yurydelendik edited a comment on Issue #1466:
@yurydelendik is it required around __deregister_frame though?
Good question. I would expect the api the by "symmetrical", means that if whatever is fed to __register_frame shall be passed to __deregister_frame. (FWIW this hole API confusing)
Is it possible to check if 1) the current __deregister_frame code de-registers FDEs; 2) does not add addition O(n^2) complexity for gcc unwind ?
Wasmtime GitHub notifications bot (Apr 16 2020 at 18:33):yurydelendik edited a comment on Issue #1466:
@yurydelendik is it required around __deregister_frame though?
Good question. I would expect the api be "symmetrical", means that if whatever is fed to __register_frame shall be passed to __deregister_frame. (FWIW this hole API confusing)
Is it possible to check if 1) the current __deregister_frame code de-registers FDEs; 2) does not add addition O(n^2) complexity for gcc unwind ?
Wasmtime GitHub notifications bot (Apr 16 2020 at 18:36):yurydelendik edited a comment on Issue #1466:
@yurydelendik is it required around __deregister_frame though?
Good question. I would expect the api be "symmetrical", means that if whatever is fed to __register_frame shall be passed to __deregister_frame. (FWIW this hole API confusing)
Is it possible to check if 1) the current __deregister_frame code de-registers FDEs; 2) does not add additional O(n^2) complexity for gcc unwind ?
Wasmtime GitHub notifications bot (Apr 16 2020 at 19:06):peterhuene commented on Issue #1466:
I agree that the underlying API here is a mess. The code I have now should cause symmetrical invocations of
__register_frameand__deregister_frame, but in the case of libgcc, only one invocation of each per code memory entry.From what I can decipher of the registration code in libgcc,
__register_framewill walk all of the FDEs from the given "base entry" (skipping over CIEs), but it only stores the "base entry" address internally for deregistration and therefore only needs the single matching__deregister_framecall. It appears that__register_frameeffectively accepts what we (and gimli) call a frame table.What libgcc is calling a "frame table" for use with
__register_frame_tableseems to be an array of pointers to those "base entries", allowing you to register frames from multiple "translation units" with a single call. To put it another way, this function would be used if we wanted to register multiple frame tables from our perspective. Technically we could use__register_frame_tableto register the frame tables for all code memory entries in a single call, but I think that would require a bit of refactoring to make work.
Wasmtime GitHub notifications bot (Apr 16 2020 at 19:48):yurydelendik commented on Issue #1466:
_register_frame will walk all of the FDEs from the given "base entry" (skipping over CIEs)
Yeah, that's confirms my analysis as well. Thanks. I guess we good to go. :+1:
Wasmtime GitHub notifications bot (Apr 16 2020 at 19:49):yurydelendik edited a comment on Issue #1466:
_register_frame will walk all of the FDEs from the given "base entry" (skipping over CIEs)
Yeah, that confirms my analysis as well. Thanks. I guess we good to go. :+1:
Last updated: Dec 23 2024 at 12:05 UTC