This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [1/9][RFC][DWARF] Reserve three DW_OP numbers in vendor extension space

On Wed, 2016-11-16 at 10:00 +0000, Jiong Wang wrote:
>   The two operations DW_OP_AARCH64_paciasp and DW_OP_AARCH64_paciasp_deref were
> designed as shortcut operations when LR is signed with A key and using
> function's CFA as salt.  This is the default behaviour of return address
> signing so is expected to be used for most of the time.  DW_OP_AARCH64_pauth
> is designed as a generic operation that allow describing pointer signing on
> any value using any salt and key in case we can't use the shortcut operations
> we can use this.

I admit to not fully understand the salting/keying involved. But given
that the DW_OP space is really tiny, so we would like to not eat up too
many of them for new opcodes. And given that introducing any new DW_OPs
using for CFI unwinding will break any unwinder anyway causing us to
update them all for this new feature. Have you thought about using a new
CIE augmentation string character for describing that the return
address/link register used by a function/frame is salted/keyed?

This seems a good description of CIE records and augmentation

It obviously also involves updating all unwinders to understand the new
augmentation character (and possible arguments). But it might be more
generic and saves us from using up too many DW_OPs.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]