From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 33590 invoked by alias); 11 Nov 2016 19:39:11 -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 33532 invoked by uid 89); 11 Nov 2016 19:39:10 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.8 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=rsn, vendor X-Spam-User: qpsmtpd, 2 recipients X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 11 Nov 2016 19:39:09 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id E1A7A1072; Fri, 11 Nov 2016 19:39:07 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-204-19.brq.redhat.com [10.40.204.19]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uABJd6O7001979 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 11 Nov 2016 14:39:07 -0500 Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id uABJd33l032422; Fri, 11 Nov 2016 20:39:03 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id uABJcxhv032421; Fri, 11 Nov 2016 20:38:59 +0100 Date: Fri, 11 Nov 2016 19:39:00 -0000 From: Jakub Jelinek To: Jiong Wang Cc: gcc-patches , gdb-patches@sourceware.org, Binutils , "Richard Earnshaw (lists)" Subject: Re: [1/9][RFC][DWARF] Reserve three DW_OP numbers in vendor extension space Message-ID: <20161111193859.GJ3541@tucnak.redhat.com> Reply-To: Jakub Jelinek References: <72418e98-a400-c503-e8ce-c3fbe1ecc4a7@foss.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <72418e98-a400-c503-e8ce-c3fbe1ecc4a7@foss.arm.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-SW-Source: 2016-11/txt/msg00299.txt.bz2 On Fri, Nov 11, 2016 at 06:21:48PM +0000, Jiong Wang wrote: > This patch introduces three AARCH64 private DWARF operations in vendor extension > space. > > DW_OP_AARCH64_pauth 0xea > === > Takes one unsigned LEB 128 Pointer Authentication Description. Bits [3:0] of > the description contain the Authentication Action Code. All unused bits are > initialized to 0. The operation then proceeds according to the value of the > action code as described in the Action Code Table. > > DW_OP_AARCH64_paciasp 0xeb > === > Authenticates the contents in X30/LR register as per A key for instruction > pointer using current CFA as salt. The result is pushed onto the stack. > > DW_OP_AARCH64_paciasp_deref 0xec > === > Takes one signed LEB128 offset and retrieves 8-byte contents from the address > calculated by CFA plus this offset, the contents then authenticated as per A > key for instruction pointer using current CFA as salt. The result is pushed > onto the stack. I'd like to point out that especially the vendor range of DW_OP_* is extremely scarce resource, we have only a couple of unused values, so taking 3 out of the remaining unused 12 for a single architecture is IMHO too much. Can't you use just a single opcode and encode which of the 3 operations it is in say the low 2 bits of a LEB 128 operand? We'll likely need to do RSN some multiplexing even for the generic GNU opcodes if we need just a few further ones (say 0xff as an extension, followed by uleb128 containing the opcode - 0xff). In the non-vendor area we still have 54 values left, so there is more space for future expansion. Jakub