Stream: git-wasmtime

Topic: wasmtime / issue #3274 A round of Mac M1 fixes


view this post on Zulip Wasmtime GitHub notifications bot (Sep 02 2021 at 08:14):

bnjbvr commented on issue #3274:

Seems that CI is running cargo check for 1.43 with a comment (from last year) stating it's necessary for Firefox, however Firefox has been updated to use 1.54 according to https://bugzilla.mozilla.org/show_bug.cgi?id=1723016. Can we remove this requirement now? (Of course can tweak the code to not use _or_ patterns.)

view this post on Zulip Wasmtime GitHub notifications bot (Sep 06 2021 at 12:15):

akirilov-arm commented on issue #3274:

@alexcrichton @bnjbvr I have just seen this:

The pushes in wasmtime_fiber_switch start with stp lr, fp, [sp, -16]!, so FP was at CFA - 0x8, not CFA - 0x60. Unclear why it did work in the first place, and why it stopped working at some point; likely that something in Apple's libunwind has changed in the meanwhile.

Is there any specific reason to push the registers in that order? The Procedure Call Standard actually specifies the reverse:

The lowest addressed double-word shall point to the previous frame record and the highest addressed double-word shall contain the value passed in LR on entry to the current function.

view this post on Zulip Wasmtime GitHub notifications bot (Sep 06 2021 at 12:23):

bnjbvr commented on issue #3274:

Is there any specific reason to push the registers in that order? The Procedure Call Standard actually specifies the reverse:

No, no particular reasons. One could easily get confused with the push order in stp...

view this post on Zulip Wasmtime GitHub notifications bot (Sep 07 2021 at 11:41):

akirilov-arm commented on issue #3274:

Perhaps that is the cause of the issue with libunwind? I.e. maybe the unwinder has been changed to have stricter frame record layout expectations?

view this post on Zulip Wasmtime GitHub notifications bot (Sep 07 2021 at 11:43):

akirilov-arm edited a comment on issue #3274:

Perhaps that is partially the cause of the issue with libunwind? I.e. maybe the unwinder has been changed to have stricter frame record layout expectations in thee presence of incorrect CFI information?

view this post on Zulip Wasmtime GitHub notifications bot (Sep 07 2021 at 11:43):

akirilov-arm edited a comment on issue #3274:

Perhaps that is partially the cause of the issue with libunwind? I.e. maybe the unwinder has been changed to have stricter frame record layout expectations (in the presence of incorrect CFI information)?

view this post on Zulip Wasmtime GitHub notifications bot (Sep 07 2021 at 11:45):

bnjbvr commented on issue #3274:

Perhaps that is partially the cause of the issue with libunwind? I.e. maybe the unwinder has been changed to have stricter frame record layout expectations (in the presence of incorrect CFI information)?

No: the change in this PR was sufficient to make the test pass, and it wouldn't have been the case if the unwinder had very precise frame record layout expectations. That being said, I'm all in favor of using the most conforming push order :-)

view this post on Zulip Wasmtime GitHub notifications bot (Sep 08 2021 at 14:23):

alexcrichton commented on issue #3274:

Nah there is no reason to push the registers in that order, only that I'd never written arm64 assembly before when I wrote this. I think it would be best to follow arm64 conventions and standards though!


Last updated: Dec 23 2024 at 12:05 UTC