[Ping^3][1/9][RFC][DWARF] Reserve three DW_OP numbers in vendor extension space

[Jiong Wang <jiong dot wang at foss dot arm dot com>]

Jiong Wang writes:

> Jiong Wang writes:
>
>> 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  <rearnsha@arm.com>
>>>               Jiong Wang  <jiong.wang@arm.com>
>>>
>>>          * dwarf2.def (DW_OP_AARCH64_operation): Reserve the number 0xea.
>>
>> Ping~
> Ping^2

Ping^3

Can DWARF maintainers or global reviewers have a look at this?

Thanks very much.

-- 
Regards,
Jiong