From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27313 invoked by alias); 15 Nov 2016 16:00:47 -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 27252 invoked by uid 89); 15 Nov 2016 16:00:46 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.7 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=unavailable version=3.3.2 spammy=Binutils, offer, reserved, vendor 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; Tue, 15 Nov 2016 16:00:44 +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 BEF47AD7; Tue, 15 Nov 2016 08:00:42 -0800 (PST) Received: from [10.2.206.198] (e104437-lin.cambridge.arm.com [10.2.206.198]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id DC19C3F24D; Tue, 15 Nov 2016 08:00:41 -0800 (PST) Subject: Re: [1/9][RFC][DWARF] Reserve three DW_OP numbers in vendor extension space To: Jakub Jelinek References: <72418e98-a400-c503-e8ce-c3fbe1ecc4a7@foss.arm.com> <20161111193859.GJ3541@tucnak.redhat.com> Cc: gcc-patches , gdb-patches@sourceware.org, Binutils , "Richard Earnshaw (lists)" From: Jiong Wang Message-ID: Date: Tue, 15 Nov 2016 16:00:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20161111193859.GJ3541@tucnak.redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2016-11/txt/msg00372.txt.bz2 On 11/11/16 19:38, Jakub Jelinek wrote: > 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 Seperate DWARF operations are introduced instead of combining all of them into one are mostly because these operations are going to be used for most of the functions once return address signing are enabled, and they are used for describing frame unwinding that they will go into unwind table for C++ program or C program compiled with -fexceptions, the impact on unwind table size is significant. So I was trying to lower the unwind table size overhead as much as I can. IMHO, three numbers actually is not that much for one architecture in DWARF operation vendor extension space as vendors can overlap with each other. The only painful thing from my understand is there are platform vendors, for example "GNU" and "LLVM" etc, for which architecture vendor can't overlap with. In include/dwarf2.def, I saw DW_OP_GNU* has reserved 13, DW_OP_HP* has reserved 7 and DW_OP_PGI has reserved 1. So for an alternative approach, can these AArch64 extensions overlap and reuse those numbers reserved for DW_OP_HP* ? for example 0xe4, 0xe5, 0xe6. I am even thinking GNU toolchain makes the 8 numbers reserved by existed DW_OP_HP* and DW_OP_SGI* as architecture vendor area and allow multiplexing on them for different architectures. This may offer more flexibilities for architecture vendors. Under current code base, my search shows the overlap should be safe inside GCC/GDB and we only needs minor disassemble tweak in Binutils. Thanks. Regards, Jiong