From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 126357 invoked by alias); 12 Dec 2016 13:40:20 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 125921 invoked by uid 89); 12 Dec 2016 13:40:11 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.0 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=Wang, wang, signing, salted X-Spam-User: qpsmtpd, 2 recipients X-HELO: foss.arm.com Received: from foss.arm.com (HELO foss.arm.com) (217.140.101.70) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 12 Dec 2016 13:40:01 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 787FAAD7; Mon, 12 Dec 2016 05:39:59 -0800 (PST) Received: from e104437-lin (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 7579C3F477; Mon, 12 Dec 2016 05:39:58 -0800 (PST) References: <72418e98-a400-c503-e8ce-c3fbe1ecc4a7@foss.arm.com> <20161111193859.GJ3541@tucnak.redhat.com> <20161115161817.GL3541@tucnak.redhat.com> <5896be40-51de-55f7-f4a1-4c5af7ff9aec@foss.arm.com> <1479304496.14569.256.camel@redhat.com> <20161116140218.GU3541@tucnak.redhat.com> <07b84003-4e73-8a7f-f949-4c3500e4ffc4@foss.arm.com> From: Jiong Wang To: Jakub Jelinek , Mark Wielaard Cc: "Richard Earnshaw \(lists\)" , gcc-patches , gdb-patches@sourceware.org, Binutils Subject: Re: [Ping~][1/9][RFC][DWARF] Reserve three DW_OP numbers in vendor extension space Date: Mon, 12 Dec 2016 13:40:00 -0000 In-reply-to: <07b84003-4e73-8a7f-f949-4c3500e4ffc4@foss.arm.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2016-12/txt/msg00268.txt.bz2 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 > Jiong Wang > > * dwarf2.def (DW_OP_AARCH64_operation): Reserve the number 0xea. Ping~ Thanks. -- Regards, Jiong