[libunwind] [llvm] [MC][AArch64] Add .cfi_llvm_set_ra_sign_state for PAuth_LR (PR #205442)

[Jon Roelofs via cfe-commits]

jroelofs wrote:

> Thinking out loud: when LR is signed using SP value only, this results in assembly like this
> 
> ```
>     paciasp
>     .cfi_negate_ra_state
> ```
> 
> But when both SP and PC are used to sign LR, the following is emitted:
> 
> ```
> ; Before this patch:
> 
>      hint #39
>      .cfi_negate_ra_state_with_pc
>    .Ltmp0:
>      paciasp
>      
> ; After this patch:
> 
>      hint #39
>      .cfi_set_ra_state 2, .Ltmp0
>    .Ltmp0:
>      paciasp
> ```
> 
> I'm not an expert in DWARF, but do I get it right: ideally, we would like to emit the CFI directive after the `pac*` instruction to produce an accurate register states (I assume this, as we have no precise restriction on `.cfi_negate_ra_state` placement). But with `.cfi_negate_ra_state_with_pc`, the PC value when this DWARF instruction is evaluated does matter, resulting in a suboptimal placement _before_ the `pac*` instruction? If that is actually the case, with `.cfi_set_ra_state` we _may_ have a chance to place it after `pac*`, the same way it is done for `.cfi_negate_ra_state`.

@DanielKristofKiss @Stylie777 re: https://github.com/llvm/llvm-project/issues/137802, do you know why we have this discontinuity between PAuth and PAuth_LR'd frames? Why do we emit `.cfi_negate_ra_state_with_pc` _before_ the `pacibsppc`, when all other CFI's take effect after the preceding instruction has retired?

> (Though, I do understand it might not be worth, say, complicating the asm printer)

On first thought, I think it would just complicate `AArch64PointerAuthImpl::authenticateLR`. Fixing it up in ASMPrinter after the fact sounds bad too, I guess unless we always emit `buildSetRAState`, and then have ASMPrinter decide whether to re-write that into negates. WDYT?

https://github.com/llvm/llvm-project/pull/205442