This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
[Ping^2][1/9][RFC][DWARF] Reserve three DW_OP numbers in vendor extension space
- From: Jiong Wang <jiong dot wang at foss dot arm dot com>
- To: Jakub Jelinek <jakub at redhat dot com>, Mark Wielaard <mjw at redhat dot com>
- Cc: "Richard Earnshaw \(lists\)" <Richard dot Earnshaw at arm dot com>, gcc-patches <gcc-patches at gcc dot gnu dot org>, gdb-patches at sourceware dot org, Binutils <binutils at sourceware dot org>, Jason Merrill <jason at redhat dot com>, ccoutant at gmail dot com
- Date: Mon, 19 Dec 2016 13:54:50 +0000
- Subject: [Ping^2][1/9][RFC][DWARF] Reserve three DW_OP numbers in vendor extension space
- Authentication-results: sourceware.org; auth=none
- References: <c9da17a6-c3de-4466-c023-4e4ddbe38efb@foss.arm.com> <72418e98-a400-c503-e8ce-c3fbe1ecc4a7@foss.arm.com> <20161111193859.GJ3541@tucnak.redhat.com> <e69bcade-9596-7679-ebfe-d0c56e24f8b5@foss.arm.com> <20161115161817.GL3541@tucnak.redhat.com> <5896be40-51de-55f7-f4a1-4c5af7ff9aec@foss.arm.com> <ceb9dfac-9f94-0d78-7f3f-8f9e0a2abb66@arm.com> <bd3dae26-48c9-9f37-a1c8-001982cb6c78@foss.arm.com> <1479304496.14569.256.camel@redhat.com> <20161116140218.GU3541@tucnak.redhat.com> <07b84003-4e73-8a7f-f949-4c3500e4ffc4@foss.arm.com> <n99d1gx5kr7.fsf@foss.arm.com>
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
--
Regards,
Jiong