Now
MAIN commitmail json YAML
PR toolchain/55837
Bump LAST_REGISTER and LAST_RESTORE_REG to REGNO_ARM32_S31 for arm.
There are two numbering schemes for VFPv2 registers: s0-s31 and d0-d15.
The former is used by GCC, and the latter is by LLVM. Since libunwind was
derived from LLVM, it has never supported the former. This results in
crashes for GCC-compiled binaries in exception handler of C++, if it
encounters VFPv2 registers when unwinding frames.
This commit adds support for s0-s31 numbering to libunwind. I choose an
implementation in which VFPv2 registers are ``double-counted'' as s0-s31
AND d0-d15. This does not cause real problems, since the former is only
used by GCC, and the later is by LLVM. That is, different numbering
schemes cannot appear in a same frame. To make sure, assertions are added
in order to check this.
I've confirmed that no regression for ATF both for GCC- and LLVM-compiled
userlands.
Bump LAST_REGISTER and LAST_RESTORE_REG to REGNO_ARM32_S31 for arm.
There are two numbering schemes for VFPv2 registers: s0-s31 and d0-d15.
The former is used by GCC, and the latter is by LLVM. Since libunwind was
derived from LLVM, it has never supported the former. This results in
crashes for GCC-compiled binaries in exception handler of C++, if it
encounters VFPv2 registers when unwinding frames.
This commit adds support for s0-s31 numbering to libunwind. I choose an
implementation in which VFPv2 registers are ``double-counted'' as s0-s31
AND d0-d15. This does not cause real problems, since the former is only
used by GCC, and the later is by LLVM. That is, different numbering
schemes cannot appear in a same frame. To make sure, assertions are added
in order to check this.
I've confirmed that no regression for ATF both for GCC- and LLVM-compiled
userlands.