When unwinding through a "pac_sign_lr" opcode, we need to strip out pointer authentication bits from the address in the LR register. Previously this was done with the "autib1716" instruction, which does validate that the address in x17 is properly signed with the B key, given the reference address in x16 (SP). However - Clang has a bug [1] since Clang 19, that has caused it to generate incorrect prologues (if building with "-mbranch-protection=standard"), doing return address signing using the A key, while the unwind info says that the address should be signed using the B key. (The unwind info has no way of signaling which key to use, but the normative form uses the B key.) It also turns out that Windows doesn't do any validation of the signing of the return address when unwinding; Windows can correctly execute and do unwinding in binaries built with the buggy Clang - which might explain why the bug has passed unnoticed for so long. Therefore, doing the same and reducing the strictness here in Wine seems reasonable (in addition to doing it to work around the Clang bug). In addition to failing on unwinding in user binaries built return address signing (e.g. "-mbranch-protection=standard") with a buggy Clang, this issue also hits cases if Wine itself has been built with "-mbranch-protection=standard" in CROSSCFLAGS, with a buggy version of Clang. This is the case on e.g. Ubuntu 26.04, making those builds of Wine fail (either directly on startup, or failing only if attempting to do unwinding in user code), if running on a CPU that supports pointer authentication. --- One reason for initially handling "pac_sign_lr" with the "autib1617" instruction was that this instruction can be encoded as a hint instruction, which any CPU can execute, and CPUs not implementing pointer authentication treats it as a nop. If doing the stripping out of pointer authentication using "xpaci", then we must only execute that instruction on CPUs that support it. There is no flag for IsProcessorFeaturePresent for checking for pointer authentication. (Also, we can't just assemble the instruction as such without enabling pointer authentication support in the assembler - but we can assemble it using ".inst".) Instead, do pointer signing using the regular "pacibsp" instruction (which can be encoded as a hint instruction) and check if it results in changed bits in the address. And in case the B key would happen to be disabled (resulting in no changed bits) while the code erroneously signs using the A key (if that one is enabled), also check if "paciasp" changes any bits. If either of them changes bits, we can be sure that pointer authentication is available and we can execute the "xpaci" instruction. [1] https://github.com/llvm/llvm-project/issues/203852 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11155