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.)
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.
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
...
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?
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?
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)?
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 :-)
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: Nov 22 2024 at 17:03 UTC