| Summary: | arm64 backend: incorrect code emitted for doubleword CAS | ||
|---|---|---|---|
| Product: | [Developer tools] valgrind | Reporter: | Julian Seward <jseward> |
| Component: | vex | Assignee: | Julian Seward <jseward> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | mark |
| Priority: | NOR | ||
| Version First Reported In: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Bug Depends on: | |||
| Bug Blocks: | 444399 | ||
Fixed, 7dbe2fed72886874f2eaf57dc07929542ae55b58. |
The sequence of instructions emitted by the arm64 backend for doubleword compare-and-swap is incorrect. This could lead to incorrect simulation of the AArch8.1 atomic instructions (CASP, at least), and causes failures in the upcoming fix for v8.0 support for LD{,A}XP/ST{,L}XP in bug 444399. In the worst case it can cause segfaulting in the generated code, because it could jump backwards unexpectedly far. The problem is the sequence emitted for ARM64in_CASP: * the jump offsets are incorrect, both for `bne out` (x 2) and `cbnz w1, loop`. * using w1 to hold the success indication of the stxp instruction trashes the previous value in x1. But the value in x1 is an output of ARM64in_CASP, hence one of the two output registers is corrupted. That confuses any code downstream that want to inspect those values to find out if the transaction succeeded or not. The fixes are to * fix the branch offsets * use a different register to hold the stxp success indication. w3 is a convenient check.