From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19768 invoked by alias); 30 Nov 2016 21:44:10 -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 19725 invoked by uid 89); 30 Nov 2016 21:44:09 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=H*F:U*ccoutant, picking X-Spam-User: qpsmtpd, 2 recipients X-HELO: mail-qk0-f195.google.com Received: from mail-qk0-f195.google.com (HELO mail-qk0-f195.google.com) (209.85.220.195) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 30 Nov 2016 21:43:59 +0000 Received: by mail-qk0-f195.google.com with SMTP id x190so23755845qkb.0; Wed, 30 Nov 2016 13:43:59 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5BkPajIeFYRuWv+KOmjLGW+hsm+PwZoId8rYywnj51g=; b=ZqgZwI4zHacaNbWsMGiw6PSN47kZpxlI0yR0A07AOO8vT6YARlqWlmSyg4EJL4NNOE ViWwch4K1yi4dfv8yyTNkUOGZbLSgCLMphxgjH2r367GQph2v3/bpA87PqvO1ofg3Kue +lbf7kW47bs6hReWdbw7CvJ/+83SBeSvearvIZDOycFfMNoJxV9kndx9zybAGy57Vncy lmbTQj7J0IJA+DrezX0zz8nF8dF/FkGZbg2fD644WQntTfYxKtKII7YZle+949CbnbHq i4bXMNLeYvQvWvGKH8n5J6xV3XqKNxiTdFWP4EbOA9ub9vTotfg9Ejg0e8q0+KcqVohb K/tw== X-Gm-Message-State: AKaTC03f5Mjgyl5xM5rL3EaiutMfv43WBBr0WDvRkG+4N7/wkQAcTAiZU+zVX8kQ+p68YECqcp+eBWnW6tTwlw== X-Received: by 10.55.88.197 with SMTP id m188mr29314855qkb.322.1480542237720; Wed, 30 Nov 2016 13:43:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.237.38.2 with HTTP; Wed, 30 Nov 2016 13:43:57 -0800 (PST) In-Reply-To: <20161116140218.GU3541@tucnak.redhat.com> 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> From: Cary Coutant Date: Wed, 30 Nov 2016 21:44:00 -0000 Message-ID: Subject: Re: [1/9][RFC][DWARF] Reserve three DW_OP numbers in vendor extension space To: Jakub Jelinek Cc: Mark Wielaard , Jiong Wang , "Richard Earnshaw (lists)" , gcc-patches , GDB , Binutils Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2016-11/txt/msg01027.txt.bz2 How about if instead of special DW_OP codes, you instead define a new virtual register that contains the mangled return address? If the rule for that virtual register is anything other than DW_CFA_undefined, you'd expect to find the mangled return address using that rule; otherwise, you would use the rule for LR instead and expect an unmangled return address. The earlier example would become (picking an arbitrary value of 120 for the new virtual register number): .cfi_startproc 0x0 paciasp (this instruction sign return address register LR/X30) .cfi_val 120, DW_OP_reg30 0x4 stp x29, x30, [sp, -32]! .cfi_offset 120, -16 .cfi_offset 29, -32 .cfi_def_cfa_offset 32 0x8 add x29, sp, 0 Just a suggestion... -cary On Wed, Nov 16, 2016 at 6:02 AM, 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