From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 122388 invoked by alias); 16 Nov 2016 12:16:32 -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 122110 invoked by uid 89); 16 Nov 2016 12:16:32 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=BAYES_20,MIME_BASE64_BLANKS,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=H*r:sk:orsmga1, H*r:10.253.24, d2, D2 X-HELO: mga03.intel.com Received: from mga03.intel.com (HELO mga03.intel.com) (134.134.136.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 16 Nov 2016 12:16:21 +0000 Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga103.jf.intel.com with ESMTP; 16 Nov 2016 04:16:19 -0800 X-ExtLoop1: 1 Received: from heckel-mobl3.ger.corp.intel.com (HELO [172.28.205.41]) ([172.28.205.41]) by fmsmga006.fm.intel.com with ESMTP; 16 Nov 2016 04:16:18 -0800 Subject: Re: [PATCH V4 5/6] Resolve dynamic target types of pointers. To: Yao Qi References: <1473230295-809-1-git-send-email-bernhard.heckel@intel.com> <1473230295-809-6-git-send-email-bernhard.heckel@intel.com> <86k2dc8hri.fsf@gmail.com> <57FFA0CC.1040800@intel.com> <86bmyj8dwf.fsf@gmail.com> <5804B509.7050103@intel.com> <5804C179.6090401@intel.com> <5821799A.6000708@intel.com> Cc: Joel Brobecker , "gdb-patches@sourceware.org" From: Bernhard Heckel Message-ID: <582C4E11.2010904@intel.com> Date: Wed, 16 Nov 2016 12:16:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format="flowed" Content-Transfer-Encoding: base64 X-IsSubscribed: yes X-SW-Source: 2016-11/txt/msg00410.txt.bz2 T24gMDgvMTEvMjAxNiAxMjoyNiwgWWFvIFFpIHdyb3RlOgo+IE9uIFR1ZSwg Tm92IDgsIDIwMTYgYXQgNzowNyBBTSwgQmVybmhhcmQgSGVja2VsCj4gPGJl cm5oYXJkLmhlY2tlbEBpbnRlbC5jb20+IHdyb3RlOgo+PiBDcmVhdGVkIGEg dGlja2V0Cj4+IGh0dHBzOi8vZ2NjLmdudS5vcmcvYnVnemlsbGEvc2hvd19i dWcuY2dpP2lkPTc4MDU5Cj4+Cj4+IENhbiB3ZSBhZ3JlZSB0byBtb3ZlIGZv cndhcmQgd2l0aCBhICJrbm93biBmYWlsIiBmb3IgR2ZvcnRyYW4/Cj4+Cj4g Q2FuIHdlIHdhaXQgdW50aWwgUFIgNzgwNTkgaXMgY29uZmlybWVkIGJ5IGdm b3J0cmFuIHBlb3BsZT8KPgoKRFdBUkY0IGdpdmVzIGFuIGltcGxlbWVudGF0 aW9uIHByb3Bvc2FsIG9mIGFycmF5IHBvaW50ZXJzIGFuZCBpdCBpcyBsaWtl IApHZm9ydHJhbiBpcwppbXBsZW1lbnRpbmcgaXQuCi0+ICBTZWUgRC4yIEFn Z3JlZ2F0ZSBFeGFtcGxlcwogICAgLT4gISBEZXNjcmlwdGlvbiBmb3IgdHlw ZSBvZiAnYXAnCgpTbywgR2ZvcnRyYW4gaXMgb2sgaGVyZS4KCgoKSW50ZWwg RGV1dHNjaGxhbmQgR21iSApSZWdpc3RlcmVkIEFkZHJlc3M6IEFtIENhbXBl b24gMTAtMTIsIDg1NTc5IE5ldWJpYmVyZywgR2VybWFueQpUZWw6ICs0OSA4 OSA5OSA4ODUzLTAsIHd3dy5pbnRlbC5kZQpNYW5hZ2luZyBEaXJlY3RvcnM6 IENocmlzdGluIEVpc2Vuc2NobWlkLCBDaHJpc3RpYW4gTGFtcHJlY2h0ZXIK Q2hhaXJwZXJzb24gb2YgdGhlIFN1cGVydmlzb3J5IEJvYXJkOiBOaWNvbGUg TGF1ClJlZ2lzdGVyZWQgT2ZmaWNlOiBNdW5pY2gKQ29tbWVyY2lhbCBSZWdp c3RlcjogQW10c2dlcmljaHQgTXVlbmNoZW4gSFJCIDE4NjkyOAo= >From gdb-patches-return-134871-listarch-gdb-patches=sources.redhat.com@sourceware.org Wed Nov 16 13:55:10 2016 Return-Path: Delivered-To: listarch-gdb-patches@sources.redhat.com Received: (qmail 53733 invoked by alias); 16 Nov 2016 13:55: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 Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 52230 invoked by uid 89); 16 Nov 2016 13:55:09 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2 spammy=cie, cfi, CFI, CIE X-Spam-User: qpsmtpd, 2 recipients X-HELO: tarox.wildebeest.org Received: from herd.wildebeest.org (HELO tarox.wildebeest.org) (80.127.118.209) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 16 Nov 2016 13:54:59 +0000 Received: by tarox.wildebeest.org (Postfix, from userid 1000) id 17959413CABC; Wed, 16 Nov 2016 14:54:57 +0100 (CET) Message-ID: <1479304496.14569.256.camel@redhat.com> Subject: Re: [1/9][RFC][DWARF] Reserve three DW_OP numbers in vendor extension space From: Mark Wielaard To: Jiong Wang Cc: "Richard Earnshaw (lists)" , Jakub Jelinek , gcc-patches , gdb-patches@sourceware.org, Binutils Date: Wed, 16 Nov 2016 13:55:00 -0000 In-Reply-To: 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> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 X-SW-Source: 2016-11/txt/msg00411.txt.bz2 Content-length: 1358 On Wed, 2016-11-16 at 10:00 +0000, Jiong Wang wrote: > The two operations DW_OP_AARCH64_paciasp and DW_OP_AARCH64_paciasp_dere= f 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_pa= uth > 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 operat= ions > 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. Cheers, Mark