Jiong Wang writes: > On 16/11/16 14:02, Jakub Jelinek wrote: >> On Wed, Nov 16, 2016 at 02:54:56PM +0100, Mark Wielaard wrote: >>> 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 >>> characters:http://www.airs.com/blog/archives/460 >>> >>> 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. >> >> From what I understood, the return address is not always scrambled, so >> it doesn't apply to the whole function, just to most of it (except for >> an insn in the prologue and some in the epilogue). So I think one op is >> needed. But can't it be just a toggable flag whether the return address >> is scrambled + some arguments to it? >> Thus DW_OP_AARCH64_scramble .uleb128 0 would mean that the default >> way of scrambling starts here (if not already active) or any kind of >> scrambling ends here (if already active), and >> DW_OP_AARCH64_scramble .uleb128 non-zero would be whatever encoding you need >> to represent details of the less common variants with details what to do. >> Then you'd just hook through some MD_* macro in the unwinder the >> descrambling operation if the scrambling is active at the insns you unwind >> on. >> >> Jakub > > Hi Mark, Jakub: > > Thanks very much for the suggestions. > > I have done some experiments on your ideas and am thinking it's good to > combine them together. The use of DW_CFA instead of DW_OP can avoid > building > all information from scratch at each unwind location, while we can indicate > the signing key index through new AArch64 CIE augmentation 'B'. This new > approach reduce the unwind table size overhead from ~25% to ~5% when return > address signing enabled, it also largely simplified dwarf generation code > for > return address signing. > > As one new DWARF call frame instruction is needed for AArch64, I want to > reuse > DW_CFA_GNU_window_save to save the space. It is in vendor extension space > and > used for Sparc only, I think it make sense to reuse it for AArch64. On > AArch64, DW_CFA_GNU_window_save toggle return address sign status which > kept > in a new boolean type column in DWARF table, so DW_CFA_GNU_window_save > takes > no argument on AArch64, the same as on Sparc, this makes no difference to > those > existed encoding, length calculation code. > > Meanwhile one new DWARF expression operation number is still needed for > AArch64, it's useful for describing those complex pointer signing scenarios > and it will be used to multiplex some further extensions on AArch64. > > OK on this proposal and to install this patch to gcc trunk? > > Hi GDB, Binutils maintainer: > > OK on this proposal and install this patch to binutils-gdb master? > > include/ > 2016-11-29 Richard Earnshaw <rearn...@arm.com> > Jiong Wang <jiong.w...@arm.com> > > * dwarf2.def (DW_OP_AARCH64_operation): Reserve the number 0xea.
Ping~ Thanks. -- Regards, Jiong