As reported in LLVM bug 41486, the check (byte1 & 0xf8) == 0xc0 is wrong. We want to check for 11010nnn,
so the proper value we want to compare against is 0xd0 (0xc0 would check for the value 11000nnn which we
already checked for above as described in the bug report).
Details
- Reviewers
jasonmolenda - Group Reviewers
Restricted Project - Commits
- rGbef588ce11ef: Fix typo in ArmUnwindInfo::GetUnwindPlan
rLLDB358479: Fix typo in ArmUnwindInfo::GetUnwindPlan
rL358479: Fix typo in ArmUnwindInfo::GetUnwindPlan
Diff Detail
- Repository
- rL LLVM
Event Timeline
Don't have the test for this and probably can't write one for it (as I don't have access to an ARM device for testing and don't really know the code so well). If anyone feels like providing a test, feel free to link it to this revision.
Agreed, this change is correct. I double checked this in the http://infocenter.arm.com/help/topic/com.arm.doc.ihi0038b/IHI0038B_ehabi.pdf doc (mod 24 Nov 2015) and the only difference in Section 9.3 "Frame unwinding instructions" Table 4 and this code is in the comment - they now refer to this as 'Pop VFP double-precision registers D[8]-D[8+nnn] saved (as if) by VPUSH (see remark d)'. But there's no benefit in updating this one comment while the others are using the older comments (this code was originally written against the 30 Nov 2012 version of the doc).
We don't have any tests for the ARM.exidx exception handling information today, it would be take some work to add that. It's a format like darwin's compact unwind or less correctly, eh_frame, only defined for 32-bit arm. I would commit this obvious fix without a test.