Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[X86][MC] Reject out-of-range control and debug registers encoded wit…
…h APX (llvm#82584) Fixes llvm#82557. APX specification states that the high bits found in REX2 used to encode GPRs can also be used to encode control and debug registers, although all of them will #UD. Therefore, when disassembling we reject attempts to create control or debug registers with a value of 16 or more. See page 22 of the [specification](https://www.intel.com/content/www/us/en/developer/articles/technical/advanced-performance-extensions-apx.html): > Note that the R, X and B register identifiers can also address non-GPR register types, such as vector registers, control registers and debug registers. When any of them does, the highest-order bits REX2.R4, REX2.X4 or REX2.B4 are generally ignored, except when the register being addressed is a control or debug register. [...] The exception is that REX2.R4 and REX2.R3 [*sic*] are not ignored when the R register identifier addresses a control or debug register. Furthermore, if any attempt is made to access a non-existent control register (CR*) or debug register (DR*) using the REX2 prefix and one of the following instructions: “MOV CR*, r64”, “MOV r64, CR*”, “MOV DR*, r64”, “MOV r64, DR*”. #UD is raised. The invalid encodings are 64-bit only because `0xd5` is a valid instruction in 32-bit mode.
- Loading branch information