Fix step number references in ARM64 exception handling #5114
Conversation
|
@mstorsjo : Thanks for your contribution! The author(s) have been notified to review your proposed change. |
|
Learn Build status updates of commit f04b68f: ✅ Validation status: passed
For more details, please refer to the build report. For any questions, please:
|
|
Can you review the proposed changes? IMPORTANT: When the changes are ready for publication, adding a #label:"aq-pr-triaged" |
prmerger-automator
bot
added
the
aq-pr-triaged
There was a problem hiding this comment.
@mstorsjo, thank you for updating this topic.
I don't see another reference to save_rep in the doc. The reference to "the last save_rep" is the only mention. Is that correct?
As a little nit, would you mind changing the case of Step 2 to step 2.
These step numbers were adjusted in f510c83, but we forgot to update these references here. Also fix stray capitalization, and a typo regarding save_reg.
mstorsjo
force-pushed
the
arm64-packed-step-numbers
branch
from
f04b68f to
382731a
Compare
Oh, thanks for catching this - it’s indeed another typo, it’s supposed to be save_reg; I fixed that now too.
Sure, done. |
|
Learn Build status updates of commit 382731a: ✅ Validation status: passed
For more details, please refer to the build report. For any questions, please:
|
| @@ -393,7 +393,7 @@ Step 6: Allocate remaining stack, including local area, `<x29,lr>` pair, and out | |||
| | 6d | (**CR** == 00 \|\| **CR** == 01) &&<br/>`#locsz` <= 4080 | 1 | `sub sp,sp,#locsz` | `alloc_s`/`alloc_m` | | |||
| | 6e | (**CR** == 00 \|\| **CR** == 01) &&<br/>`#locsz` > 4080 | 2 | `sub sp,sp,4080`<br/>`sub sp,sp,#(locsz-4080)` | `alloc_m`<br/>`alloc_s`/`alloc_m` | | |||
|
|
|||
| \* If **CR** == 01 and **RegI** is an odd number, Step 2 and the last `save_rep` in step 1 are merged into one `save_regp`. | |||
| \* If **CR** == 01 and **RegI** is an odd number, step 3 and the last `save_reg` in step 2 are merged into one `save_regp`. | |||
There was a problem hiding this comment.
@mstorsjo, thank you for the updates. I'm still a little confused. There is no save_reg in step 2. There's a save_regp.
There was a problem hiding this comment.
Understandable - it's not spelled out in too much detail.
In step 2, we have one save_regp_x followed by more save_regp - for each pair of registers that are backed up. If the number of registers is odd, the last one is save_reg, not save_regp, as the last one doesn't have a pair.
And for that case - if the last one is a lone register, when RegI is odd, the save of LR from step 3 (which also would have been a save_reg) is merged into a paired store of registers into save_regp.
|
#sign-off |
These step numbers were adjusted in
f510c83, but we forgot to update these references here.