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 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
