From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 61818 invoked by alias); 15 Nov 2016 16:18:28 -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 61736 invoked by uid 89); 15 Nov 2016 16:18:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.7 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=unavailable version=3.3.2 spammy=EM_*, em_*, dwz, 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; Tue, 15 Nov 2016 16:18:25 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (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 5D17C7EA82; Tue, 15 Nov 2016 16:18:24 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-204-19.brq.redhat.com [10.40.204.19]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uAFGIM5m013251 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 15 Nov 2016 11:18:23 -0500 Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id uAFGIKC4031473; Tue, 15 Nov 2016 17:18:21 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id uAFGIIPh031471; Tue, 15 Nov 2016 17:18:18 +0100 Date: Tue, 15 Nov 2016 16:18:00 -0000 From: Jakub Jelinek To: Jiong Wang , mjw@tucnak.zalov.cz 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: <20161115161817.GL3541@tucnak.redhat.com> Reply-To: Jakub Jelinek References: <72418e98-a400-c503-e8ce-c3fbe1ecc4a7@foss.arm.com> <20161111193859.GJ3541@tucnak.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-SW-Source: 2016-11/txt/msg00374.txt.bz2 On Tue, Nov 15, 2016 at 04:00:40PM +0000, Jiong Wang wrote: > >> 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. > > 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. For DW_OP_*, there aren't two vendor ranges like e.g. in ELF, there is just one range, so ideally the opcodes would be unique everywhere, if not, there is just a single GNU vendor, there is no separate range for Aarch64, that can overlap with range for x86_64, and powerpc, etc. Perhaps we could declare that certain opcode subrange for the GNU vendor is architecture specific and document that the meaning of opcodes in that range and count/encoding of their arguments depends on the architecture, but then we should document how to figure out the architecture too (e.g. for ELF base it on the containing EM_*). All the tools that look at DWARF (readelf, objdump, eu-readelf, libdw, libunwind, gdb, dwz, ...) would need to agree on that though. I know nothing about the aarch64 return address signing, would all 3 or say 2 usually appear together without any separate pc advance, or are they all going to appear frequently and at different pcs? Perhaps if there is just 1 opcode and has all the info encoded just in one bigger uleb128 or something similar... Jakub